[bastien2]

Except that doesn't work in the real world, where encrypted and authenticated boot disks are increasingly common.

So you'll need a significant amount of code that isn't the permanently-resident kernel that has enough device support to access keys and decrypt and authenticate what holds the kernel that will launch the OS.

IOW, you'll just have to reinvent a bootloader anyway.

Or you can address the problems with GRUB, extend it to do what you need, and avoid doing the traditional linux folly of Yet Another Unnecessary Reinvention.

Or was systemd vendor lock-in not enough for your shareholders?

[mjg59]

The EFI system partition is, by definition, either not encrypted or is unlocked by the firmware - your bootloader wouldn't work otherwise. In this setup, you just stick the UKI on the EFI system partition, and unlocking the rest of the drive is performed in the initramfs.

[rcxdude]

This code already exists in UEFI in the form of secure boot. The 'bootloader' (more accurately 'boot menu' IMO) kernel and its initramfs would be authenticated and unlocked by the system firmware, and then authenticate and unlock the rootfs and (optionally) different kernel for that system. It's basically going "hey, GRUB is more or less re-inventing the linux kernel, why don't we just write a simple userland for linux that does the same job but with way less code instead?"

[BobbyTables2]

Actually I don’t think UEFI firmware validates the initramfs — that is loaded by the kernel’s efi stub.

One can make a UKI image which glues the two together in a single file along with a tiny bit of code for booting it.

[ec109685]

Isn’t their argument that much of this code already exists in Linux?