I would like to preface this by saying these are risks most people will probably not realistically face.
For additional clarification, the problem with most Linux distros’ default secure boot support is that they don’t validate every boot component. A simplified boot process for most major distros looks something like:
- EFI firmware
- shim package
- bootloader
- kernel
- initramfs/microcode
- init system
- user space apps
Every step in this chain has to validate the next somehow. 6 → 7 is enforced with disk encryption, 1 → 2 is enforced with Microsoft’s certificate, 2 → 3 is enforced by the distro’s certificate pre-installed in the shim binary, but the rest gets pretty messy.
Click to expand: speaking of 1 → 2...
The other benefit to using custom keys is that you can replace the reliance on Microsoft’s certificate, by installing your custom key directly in your UEFI, negating the need for a Microsoft-signed shim binary. Microsoft signs many different objects with the same key, so it’s not impossible to imagine them signing something with bugs or backdoors at some point. If your UEFI doesn’t support custom keys, you’re stuck with enrolling your custom keys inside the Microsoft-signed shim, which still allows you to protect everything else I described above, but Microsoft signing something improperly remains a risk.
Typically the bootloader will verify the kernel image is correct (so 3 → 4 should be protected*), but the kernel’s EFI stub can only load an external initramfs image, and it has no code signature checks in place to prevent that external initramfs from being modified. Basically this means that there aren’t really proper verification steps going on during 4 → 5 → 6.
*grub is a little problematic here too, systemd-boot is probably preferable.
There are fixes for this, the usual fix is to create a unified kernel image which basically combines the kernel, initramfs, and microcode into one single package which can be signed for secure boot purposes. You can do this with your own keys, which is what I was alluding to when I was talking about using custom keys, but no major distros do this themselves to my knowledge.
Fedora is/was working on shipping their own unified kernel image instead of generating initrd images during the install, but it’s a long ways off from being the default, and you can probably only opt-in if your Fedora install is in a virtual machine or on very modern hardware: This is the reason distros aren’t yet shipping a unified kernel image themselves, because different hosts need different drivers during the boot process, which isn’t super compatible with the idea of sending the same unified image to everybody. Of course if you create your own unified kernel image with your own keys, you can create an image tailored to your host specifically, avoiding this problem.
All this being said, evil maid attacks being limited to initrd is still Better Than Nothing™, it limits attacks to the user space as opposed to the kernel itself, which should at least make them far easier to detect.