2

Two common ways to do Secure Boot are:

  1. EFI -> shim -> grub -> kernel
  2. EFI -> UKI

I want to keep grub, but discard all third party keys and use my own. One option would be to recompile shim with only my keys, but it seems more straightforward to do a simpler boot chain of EFI -> grub -> UKI.

So far I have:

# Install GRUB with the modules embedded grub-install --target=x86_64-efi --efi-directory=/boot/efi --boot-directory=/boot/efi/boot \ --modules="normal probe part_gpt part_msdos ext2 search fat lvm luks tpm mdraid1x mdraid09 raid5rec raid6rec all_video gzio datetime chain loadenv configfile test linux ls echo cat help" \ --no-floppy --uefi-secure-boot --force-extra-removable --disable-shim-lock # Sign with self-generated and enrolled key cp /boot/efi/boot/grub/x86_64-efi/grub.efi /boot/efi/EFI/BOOT/ cp grub.cfg /boot/efi/EFI/BOOT/grub.cfg sbsign --key MOK.key --cert MOK.crt --output /boot/efi/EFI/BOOT/grub.efi /boot/efi/EFI/BOOT/grub.efi sbsign --key MOK.key --cert MOK.crt --output /boot/efi/EFI/Linux/vmlinuz.efi /boot/efi/EFI/Linux/vmlinuz.efi efibootmgr --create -l '/EFI/BOOT/grub.efi' # grub.cfg chainloader /EFI/Linux/vmlinuz.efi boot

This setup boots, but grub does not check the signature of the UKI. It can also probably be convinced to dynamically load unsigned modules.

What do I need to do in grub.cfg to allow proper Secure Boot without shim? Is this even a reasonable thing to do, or must I always use shim to properly populate the PCRs?

Improve this question
6
  • 2
    GRUB documentation says: "The GRUB, except the chainloader command, works with the UEFI secure boot and the shim." So the answer to your question would seem to be "Do not use the chainloader command to boot Linux." Also, what purpose does GRUB serve in your desired setup that cannot be handled with just the systemd-stub within the UKI? When booting UKI under Secure Boot, you cannot specify boot options at boot time anyway - only options configured at UKI build time will be used by systemd-stub. Commented Mar 4 at 8:03
  • 1
    @telcoM GRUB can be scripted to boot fallback images, count boot attempts etc. The UKI is not so important. I am not sure that the line you quote applies even for the linux command, because in my case there is no shim to "work with". I think the following page is describing how to explicitly check signatures, but I am not sure, and presumably we still have to block dynamic module loading? gnu.org/software/grub/manual/grub/html_node/… Commented Mar 4 at 8:12
  • 2
    Those are GPG signatures, not Secure Boot signatures. As I've understood, GRUB uses UEFI firmware load_image() routine to load files, and the Secure Boot signature check is already embedded in it: if the firmware routine finds it's loading an *.efi binary with a valid signature, and it's not blacklisted, the firmware loads it into memory and marks that memory block as execution-enabled; everything else gets marked by the firmware as "not executable" using the processor's memory management unit. The shim hooks into that validation process somehow (too deep magic for me). Commented Mar 4 at 8:57
  • 2
    The shim's purpose is to non-persistently add the public key(s) embedded in the shim (and optionally the MOK) to the firmware whitelist to allow the rest of the binaries involved in the boot to be signed by the distribution builder or the machine owner, and not by the Secure Boot CA directly, for easier updates. As far as I've understood, the UEFI Secure Boot firmware still does the actual checking, just as before. Commented Mar 4 at 9:05
  • 1
    @telcoM I am not sure why GRUB even has a shim_lock verifier then. It would be great if the firmware does the checking without extra steps in GRUB. Later I'll test some more with unsigned binaries (UKI and not) Commented Mar 4 at 9:35

1 Answer 1

Reset to default
0

I don't have a complete recipe, but I'm posting an answer to compile what information I do have.

Shim and grub are designed to work together. The shim_lock verifier exists to allow GRUB to delegate signature verification to shim. Shim even tries to cause a security violation if the secondary boot loader appears to start an image without verifying it. I have compiled shim with extra prints and observed that shim's verification function is called on the UKI that I start from grub.

With this in mind, even if you do not need Microsoft's signature, the best approach is still to use shim. If you are self-signing everything, you probably want to recompile shim so that it does not come with keys from your distro.

For the no-shim case, GRUB does have its own mechanism for verifying binaries. Similarly to shim's MOK, grub brings its own key (this time in the gpg format) and it uses that to verify its config, its modules, the kernel and initramfs. You enroll the key and enable checking when calling grub-install --pubkey. Grub's signature verification can be easily disabled by setting a grub variable, so the grub console should be protected with a password. The overall mechanism seems sound and might be an enhancement to an existing SB setup. I hesitate to use it on its own because I didn't find any examples in the wild, so it might not as battle-hardened as shim+grub.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.