Hacker News Reader

Comment by struanr | Hacker News Reader

It's a pain to set up, but you can use the EFISTUB[1] capabilities of the Linux kernel to make it boot itself. Initramfs is then capable of decrypting argon2id LUKS2 partitions.

Since it requires keeping the kernel and other boot files on an unencrypted /boot partition, secure boot is a must to ensure the kernel hasn't been tampered with. Unfortunately, UEFI secure boot only supports signing one file, and so systemd-stub[2] can be used (doesn't require SystemD) to combine boot resources in a single PE binary, allowing them to be signed.

I haven't followed it personally, but this[3] tutorial seems to go over the points I covered.

[1]https://wiki.archlinux.org/title/EFISTUB [2]https://www.freedesktop.org/software/systemd/man/systemd-stu... [3]https://nwildner.com/posts/2020-07-04-secure-your-boot-proce...

View on HN

No need to pull any systemd utilities into this; the kernel can embed its initramfs within the kernel image when you build it -- just point it to either a directory containing the files that should be inside it, or a .cpio archive containing them. You can then sign that kernel image as normal and boot it directly as an EFI application.

Well, the downside to this is that you have to compile your own kernel. Totally speculative, but I think most people (who update their kernel frequently) don't do that.

You, struanr and struanr's [3] link are mixing up two different methods used to boot a kernel as an EFI application. It's a common mistake, you'll find it made a lot on the internet.

One method is EFISTUB, which is to use the kernel config CONFIG_EFI_STUB to compile the kernel as a UEFI application. That's what struanr's [1] is about. This method does not bundle the initramfs so the initramfs must be present separately on the ESP so that the kernel EFI process can find it. If you plan to use Secure Boot you can sign the kernel but not the initramfs, and AFAIK there's no way to make the kernel verify the integrity of the initramfs in any other way. So using this method defeats the purpose of Secure Boot.

The other method is to use an external UEFI stub like the one provided by systemd-boot, etc. In this case you use a tool like dracut / ukify (new in systemd v253) to create a UEFI application using an externally provided stub (systemd-boot in dracut and ukify's case, I also remember seeing a tool that used gummiboot's stub) plus a regular kernel plus the initramfs. The initramfs becomes a PE section and the stub sets up the kernel cmdline to use it. The UEFI application is thus self-contained, and signing it lets Secure Boot guarantee correctness of both the kernel and the initramfs. This is what struanr's comment and their [2] and [3] links are about, even though their comment and [3] link claim to be about EFISTUB.

Note that a lot of distributions enable CONFIG_EFI_STUB by default anyway, so even for the first method you may not have to compile your own kernel.

You can absolutely use EFISTUB with a built-in initramfs. I've done this before to simplify installing Linux into an Intel-based system with EFI.

I can't find any documentation about how to do that with CONFIG_EFI_STUB. Arch wiki, Gentoo wiki and the kernel docs all talk about specifying the initramfs as an ESP file path. Are you sure you didn't make a UKI (the second method) ?

Yes, they're sure. The kernel config option CONFIG_INITRAMFS_SOURCE lets you specify the path to either a directory or a .cpio archive. The contents of that will then be embedded into the kernel image itself during build. You end up with one binary containing the kernel code and the initramfs, and if you also enabled CONFIG_EFI_STUB, that one binary happens to also be an EFI application and you can digitally sign it for UEFI Secure Boot (or hash it and enroll the hash into the firmware instead, if you want to avoid the hassle of public/private keys -- but if you're rebuilding regularly, it works out to be the opposite; signing with a trusted key is a lot less hassle than constantly enrolling new kernel image hashes).

Thanks. TIL about CONFIG_INITRAMFS_SOURCE.

I think an unencrypted boot should also work fine with GRUB, as that too will let initramfs do the volume unlocking. I was hoping to get encrypted /boot to work.

I still need to get secure boot to work but dealing with it seems like such a pain, especially since I use various DKMS modules.

Reply on news.ycombinator.com