|
|
|
|
|
by Arnavion
1156 days ago
|
|
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. |
|