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.