For anyone looking at how to mitigate against this, a "defence in depth" approach using grub-mkstandalone [1] has always been wise. If you're building an applia

For anyone looking at how to mitigate against this, a "defence in depth" approach using grub-mkstandalone [1] has always been wise. If you're building an appliance-style system, or just want to prevent abuse of Grub features on a secure boot system, a standalone image lets you "lock" the grub config file inside the signed binary. Once you use non-default secure boot signing keys, this attack would appear to be prevented, by avoiding the changing of the config file. The config file can be adjusted to prevent using edit mode in Grub at runtime. I currently have a standalone grub image set up, with fixed path/filename kernel and initramfs in use, meaning I don't need to update the grub image unless changing the config or updating grub itself. You can then combine this with full disk encryption (dm-crypt + luks) over the entire disk including /boot [2], and get a pretty safe setup, that would mitigate against this in the first place, as well as any other attacks trying to tamper with modules/fonts/config files for grub (as they get wrapped into the signed grub binary). [1] https://wiki.archlinux.org/index.php/GRUB/Tips_and_tricks#GRUB_standalone https://wiki.archlinux.org/index.php/GRUB/Tips_and_tricks#GR... [2] https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html https://cryptsetup-team.pages.debian.net/cryptsetup/encrypte...