#103 TODO: write protect the flash by default, in all menu entries (but only in menuentries) on intel machines using pr0/4 registers

Open
opened 2 years ago by vimuser · 0 comments

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)
Sign in to join this conversation.
No Label
No Milestone
No assignee
1 Participants
Loading...
Cancel
Save
There is no content yet.