Can distros maybe consider moving to systemd-boot at some point? Systemd is already built in and can handle things like mounting pretty easily and simply.
It is a lot leaner than grub, doesn't use a billion superfluous modules. That and it is a lot easier to prevent tampering compared with the cumbersome nonsense that is grub passwords.
Oh and it enables distros to gather accurate boot times and enables booting into UEFI direct from the desktop.
It works with secureboot/shim/Hashtool. Also each distro has it's bootloader entries in separate folders to avoid accidental conflicts.
Honest question - is it really significantly easier to prevent tampering with systemd-boot? I had a look at this recently, and ended up having to modify the source (admittedly quite easily though) to avoid relying on important parameters in the config file.
I wanted to disable editing cmdline and similar from the prompt, and ended up simply compiling that feature out (along with others). I'm not sure if there's an easy way to fix this either, since the obvious way to "secure" the bootloader is via a config file, but we really need to assume the config file is editable by an attacker, and therefore compromised.
That you don't have to go build a standalone EFI image to get modules and similar embedded into the binary is certainly safer, but I would say most stock Linux bootloaders are still a fair way from being easy to prevent tampering on.
I think the main advantage here is less about tampering (if we assume neither of these bootloaders have bugs then a GRUB2 password should be as secure as its systemd-boot equivalent) but more about the fact that systemd-boot doesn't have decades of legacy cruft accumulated that's irrelevant for UEFI and thus is less prone to having disastrous bugs.
Totally agreed on the reduced cruft - when I was modifying the codebase I felt quite comfortable with the code and it's readability. Despite it being someone else's code, it was understandable and intuitive and I felt at home with it. I could see what to patch and edit, and it worked as expected without surprises. Important for something as critical as a bootloader to use principle of least astonishment.
I only picked up on tamper resistance based on the GP as I was wondering if I missed something and ended up patching unnecessarily or was misunderstanding something. It's also possible I'm using a stricter definition of tampering, as in my project I considered removing the SSD and modifying the ESP as being "in scope". I recognise for many that's not in scope, and where you fall back to relying on FDE to prevent booting the system anyway.
Isn't this the point of secureboot? Shim/Hashtool both work with systemd-boot, you can/must sign it yourself.
If you are talking about editing config, you just disable it in the config (editor no) and then nobody can just add an entry at random during the boot process.
Secure boot will ensure the bootloader binary itself is signed, but won't do anything for the config itself for obvious reasons. I was working on a high assurance scenario though, so I think my meaning of tamper resistance differed significantly from the above post.
I found the editor option, but the issue was that the config file could be edited offline to enable it again. Stripping the whole feature out of the binary solved the issue for what I needed. I guess it just goes to show there's a broad spectrum of interpretations of tamper resistance. If you're using dm-verity for example, you want to protect your cmdline parameters to at least the level of security offered by secure boot.
It is a lot leaner than grub, doesn't use a billion superfluous modules. That and it is a lot easier to prevent tampering compared with the cumbersome nonsense that is grub passwords.
Oh and it enables distros to gather accurate boot times and enables booting into UEFI direct from the desktop.
It works with secureboot/shim/Hashtool. Also each distro has it's bootloader entries in separate folders to avoid accidental conflicts.