For Unified Kernel Images, both dracut and mkinitcpio support this out of the box. This prevents the need for any homewritten scripts to make one.
dracut also supports signing these images out-of-the box. mkinitcpio will probably support this in the future with pre/post hooks.
There are multiple caveats which is not mentioned. Binding your LUKS key to PCR 0 is not a good idea as you would have potential trouble every time you do firmware updates from LVFS as an example. PCR 7 should be fine though.
It also fails to mention how Optional ROM code is loaded on a lot of PCIe drives these days. Failure to include the Microsoft signing keys into the bootchain would resolve in potentially soft-bricking of the device. You could in theory also enroll the OpROM checksums from the TPM eventlog instead.
I have also spent quite a bit of work trying to make all of this better! I wrote sbctl which tries to make key creation and signing easier for people.
I spoke about these issues at last years Open Source Firmware Conference as well.
The shim they write about is sadly something which gatekeeps kernel functionality. There is no way to have a personal key to sign kernel modules unless you include the shim into your bootchain! This makes enabling lockdown mode with dkms modules a lot harder.
Effectively enrolling the Micrsoft 3rd party key doesn’t really decrease the security of your bootchain in any way as long as your bind LUKS to PCR 7. It would prevent attacks against the shim+grub as you decide what you want to seal towards anyway. If someone tries to downgrade the shim, or boot an old vulnerable grub, this counter the issue.
Thus it’s a bit weird to care about self-enrolled keys, rejecting the 3rd party certificate but insist on sealing towards PCR7.
Most Linux distributions with existing UEFI secure boot support do so by using the GNU GRUB bootloader with a UEFI shim loader. What happens during boot is that the system EFI firmware will execute GRUB, which then executes the shim, which in turn executes the Linux kernel.
Wrong way round! The firmware (which trusts the Microsoft signing key) boots shim (which is signed by that key). Shim (which trusts a vendor key provided at build time) in turn boots GRUB (which is signed by that key).
This is a bit overcomplicated, frankly.
For Unified Kernel Images, both dracut and mkinitcpio support this out of the box. This prevents the need for any homewritten scripts to make one.
dracut also supports signing these images out-of-the box. mkinitcpio will probably support this in the future with pre/post hooks.
There are multiple caveats which is not mentioned. Binding your LUKS key to PCR 0 is not a good idea as you would have potential trouble every time you do firmware updates from LVFS as an example. PCR 7 should be fine though.
It also fails to mention how Optional ROM code is loaded on a lot of PCIe drives these days. Failure to include the Microsoft signing keys into the bootchain would resolve in potentially soft-bricking of the device. You could in theory also enroll the OpROM checksums from the TPM eventlog instead.
I have also spent quite a bit of work trying to make all of this better! I wrote sbctl which tries to make key creation and signing easier for people.
I spoke about these issues at last years Open Source Firmware Conference as well.
https://www.osfc.io/2021/talks/improving-the-secure-boot-landscape-sbctl-go-uefi/
Luckily for the author,
sbctlwas included into Gentoo just this week :)Also,
The
shimthey write about is sadly something which gatekeeps kernel functionality. There is no way to have a personal key to sign kernel modules unless you include the shim into your bootchain! This makes enablinglockdownmode withdkmsmodules a lot harder.Effectively enrolling the Micrsoft 3rd party key doesn’t really decrease the security of your bootchain in any way as long as your bind LUKS to PCR 7. It would prevent attacks against the shim+grub as you decide what you want to seal towards anyway. If someone tries to downgrade the shim, or boot an old vulnerable grub, this counter the issue.
Thus it’s a bit weird to care about self-enrolled keys, rejecting the 3rd party certificate but insist on sealing towards PCR7.
Wrong way round! The firmware (which trusts the Microsoft signing key) boots shim (which is signed by that key). Shim (which trusts a vendor key provided at build time) in turn boots GRUB (which is signed by that key).