datasheets for each platform define what values to write. do it per platform
writing these registers must be done on each boot, but could easily be avoided. i could make grubtest.cfg not have these (only grub.cfg)
that way, if you want to boot up without write protection, you can
still don't do a grub password by default. that's for custom grub hardening which the user can do, as per documentation
combined with hardening (e.g. encrypted /boot and a grub password) this can make for a very secure boot experience
writing prX registers is better than, say, chip-specific features or ifd based methods, because it can easily be undone when necessary but only by the user. malicious software running as root on a compromised OS would not be able to reflash the firmware
no idea what to do with amd systems. i'll have to figure that out
arm chromebooks are being re-added; belgin is working on grub and vitali64/gnutoo have been doing stuff with uboot. however, chromebooks already offer a way to write protect the flash, and that can simply be documented
EDIT:
also: pressing C to get to grub terminal would not have write protection
so it would only by done basically on the default entries that have all the automated boot logic. however, the user could override (and again, only the user could do that, nobody else)
datasheets for each platform define what values to write. do it per platform
writing these registers must be done on each boot, but could easily be avoided. i could make grubtest.cfg not have these (only grub.cfg)
that way, if you want to boot up without write protection, you can
still don't do a grub password by default. that's for custom grub hardening which the user can do, as per documentation
combined with hardening (e.g. encrypted /boot and a grub password) this can make for a very secure boot experience
writing prX registers is better than, say, chip-specific features or ifd based methods, because it can easily be undone when necessary but only by the user. malicious software running as root on a compromised OS would not be able to reflash the firmware
no idea what to do with amd systems. i'll have to figure that out
arm chromebooks are being re-added; belgin is working on grub and vitali64/gnutoo have been doing stuff with uboot. however, chromebooks already offer a way to write protect the flash, and that can simply be documented
EDIT:
also: pressing C to get to grub terminal would not have write protection
so it would only by done basically on the default entries that have all the automated boot logic. however, the user could override (and again, only the user could do that, nobody else)
datasheets for each platform define what values to write. do it per platform
writing these registers must be done on each boot, but could easily be avoided. i could make grubtest.cfg not have these (only grub.cfg)
that way, if you want to boot up without write protection, you can
still don't do a grub password by default. that's for custom grub hardening which the user can do, as per documentation
combined with hardening (e.g. encrypted /boot and a grub password) this can make for a very secure boot experience
writing prX registers is better than, say, chip-specific features or ifd based methods, because it can easily be undone when necessary but only by the user. malicious software running as root on a compromised OS would not be able to reflash the firmware
no idea what to do with amd systems. i'll have to figure that out
arm chromebooks are being re-added; belgin is working on grub and vitali64/gnutoo have been doing stuff with uboot. however, chromebooks already offer a way to write protect the flash, and that can simply be documented
EDIT:
also: pressing C to get to grub terminal would not have write protection
so it would only by done basically on the default entries that have all the automated boot logic. however, the user could override (and again, only the user could do that, nobody else)