This comment is particularly concerning (as is the functionality regression implied by this new "more secure" approach):
> This means for example, that an encrypted system must use an ext4 /boot partition; it is no longer possible to encrypt the /boot partition.
So, they want to let attackers modify /boot, including grub.conf and the kernel command line? This is better? Look at all these fun knobs attackers will be able to turn!
This lets you disable machine check exceptions + the iommu. That means it'll force people to use a configuration that lets attackers stick a memory probe hardware device into the system + bypass a bunch of hardware security checks. Nice!
I also found module.sig_enforce which lets the attacker disable kernel module signature verification. Sadly, I couldn't find anything that lets you directly load a kernel module from /boot.
However, init.rd lives in /boot. I wonder if its signature is verified or not. At the very least, this approach implies that attackers can piecemeal downgrade stuff early in the boot process.
On a more serious note, grub is ancient bloatware, it is way overcomplicated for what it does, it's asking to be replaced by systemd-boot distro-wide.
Look at Apple and Microsoft's bootloaders, they are dead simple and have barely changed in 20 years, it makes you wonder how the hell grub was even conceived. It has config files for config files.
grub tries to do the kitchen sink. But we live in a UEFI world now. Boot is simple. None of that is necessary anymore.
I'd like a better boot manager but I sure as hell do not want systemd cancer to spread any further. Especially not after Poettering has started a remote attestation company.
Regarding dropping support for a LUKS encrypted /boot, one of the comments chimes in with “[but] full disk encryption is mandatory in many environments in Europe for security conformity”.
Surely some user editable data has to be stored in plaintext to be able to boot a system? Does grub.cfg need to be signed by the trust chain to be able to boot?
When I hear full disk encryption, I think of what I'm using: Using the encryption feature of the disk with a password / keyphrase prompt built into the system firmware (UEFI). It is 100% transparent to any software.
The only major downside is that you need to trust the hardware manufacturer (and their FIPS certification), which is fine for my purposes, but might not be fine for state secrets or extremely valuable trade secrets.
This comment is particularly concerning (as is the functionality regression implied by this new "more secure" approach):
> This means for example, that an encrypted system must use an ext4 /boot partition; it is no longer possible to encrypt the /boot partition.
So, they want to let attackers modify /boot, including grub.conf and the kernel command line? This is better? Look at all these fun knobs attackers will be able to turn!
https://www.kernel.org/doc/Documentation/x86/x86_64/boot-opt...
This lets you disable machine check exceptions + the iommu. That means it'll force people to use a configuration that lets attackers stick a memory probe hardware device into the system + bypass a bunch of hardware security checks. Nice!
I also found module.sig_enforce which lets the attacker disable kernel module signature verification. Sadly, I couldn't find anything that lets you directly load a kernel module from /boot.
However, init.rd lives in /boot. I wonder if its signature is verified or not. At the very least, this approach implies that attackers can piecemeal downgrade stuff early in the boot process.
Have they replaced it with grub-rs yet?
On a more serious note, grub is ancient bloatware, it is way overcomplicated for what it does, it's asking to be replaced by systemd-boot distro-wide.
Look at Apple and Microsoft's bootloaders, they are dead simple and have barely changed in 20 years, it makes you wonder how the hell grub was even conceived. It has config files for config files.
grub tries to do the kitchen sink. But we live in a UEFI world now. Boot is simple. None of that is necessary anymore.
> it makes you wonder how the hell grub was even conceived
I'm wondering how much was interop with trying to boot multiple operating systems off the same disk?
Bring back Lilo!
Personally, I miss blessing my iBook with “holy penguin pee”:
https://github.com/jeffv03/yaboot/blob/master/ybin/ybin#L902
I'd like a better boot manager but I sure as hell do not want systemd cancer to spread any further. Especially not after Poettering has started a remote attestation company.
systemd-boot is only similar to systemd in name; it started as another project and was renamed.
It’s been merged into the systemd project, so one must assume that the systemd maintainers have some level of influence over it.
Remind me why I'm supposed to care who the maintainer is for a piece of software that runs for a few seconds then gets tf out of the way.
Because they're going to try to use it to make it impossible for you to run an operating system that isn't spyware.
Can you actually definitively prove this, or is this just more fearmongering from the anti-systemd crowd that I at least don't at all take seriously?
Now that's rich. Are you indirectly telling us that Arch Linux and NixOS are spyware?
Regarding dropping support for a LUKS encrypted /boot, one of the comments chimes in with “[but] full disk encryption is mandatory in many environments in Europe for security conformity”.
Surely some user editable data has to be stored in plaintext to be able to boot a system? Does grub.cfg need to be signed by the trust chain to be able to boot?
When I hear full disk encryption, I think of what I'm using: Using the encryption feature of the disk with a password / keyphrase prompt built into the system firmware (UEFI). It is 100% transparent to any software.
The only major downside is that you need to trust the hardware manufacturer (and their FIPS certification), which is fine for my purposes, but might not be fine for state secrets or extremely valuable trade secrets.
I glad that I moved to green pastures... Aka Debian.
This sort of crap keeps getting upstreamed into Debian.
Consider devuan for your next machine. I've switched almost all my linux boxes to it, and it's great.