Secureboot with UEFI bootloader and Grub2 only

Question

I'm working on a linux system and want to configure secureboot. The fun part is that I own all the pieces of the system, including the UEFI boot loader.

I was wondering if someone could tell me if I'm missing any bits of the boot process:

1. Apply power, start executing UEFI boot loader
2. UEFI bootloader has compiled-in keys that it uses to authenticate Grub2 (and grub.cfg) and start executing it
3. Grub2 receives the same key (via efi magic), uses it to authenticate kernel, and starts executing it The #3 bullet is what I'm completely unsure of. Do I need Shim, even though I'm not dealing with Microsoft CA at all? Does Grub2 have the code to validate kernel, or does it have to go through Shim?

Bottom line is that I would like to use my own key and only my own key to validate grub2 and kernel. What do I need to make that happen?

Answer 1

I would rather describe the boot process as:

1.) Apply power, start executing Secure Boot-capable UEFI firmware

2.) Firmware checks any potential bootloaders against Secure Boot key sets, which are stored in system NVRAM (or compiled-in defaults).

3.) The bootloader is supposed to check the OS kernel in the same way.

4.) In order to be Secure Boot-compliant and meaningfully effective, Linux kernel should also cryptographically check any kernel modules loaded.

Modern kernels include an optional feature for point 4): enterprise distributions' kernels like RedHat enable it automatically when booting on a Secure Boot-capable system. Custom kernels can be provided with a signing key at compilation time.

For RedHat kernels, at runtime, the list of allowed keys is (the key used to sign the main kernel) + (whatever is in the Secure Boot db key set) + (allowed keys in the MOK set used by shim.efi, if it exists).

So if you use Secure Boot and plan to use third-party kernel modules with distribution kernels, you'll need to sign them and get the signing key on the allowed list. But if you roll your own kernels and/or have taken control of your Secure Boot keys, your Secure Boot private key can be used for signing the third-party modules too.

In order for you to be able to take control of Secure Boot, your system needs to allow you to modify Secure Boot keys. There are four (sets of) keys you're interested in:

• db, the set of public certificates of allowed bootloaders and/or SHA256 checksums of allowed bootloaders
• dbx the set of public certificates and/or checksums of explicitly blacklisted bootloaders.
• KEK, the set of public certificates that are used to validate any signed updates to db
• and PK the one and only Primary Key (certificate) that is used to validate signed updates to KEK.

By default, the system should have hardware manufacturer's PK, and both Microsoft's and hardware manufacturer's keys in KEK and db. This allows the use of Microsoft-certified bootloaders (which includes the "shim" used with some Linuxes) and hardware manufacturer's firmware update tools out-of-the-box.

The first step would be examining your UEFI BIOS Setup settings very carefully. On some systems, the Setup allows both adding and deleting of all Secure Boot keys. On other systems, the only options are resetting back to the factory default keys, and clearing all keys. If your Setup requires clearing all keys in order to be able to use custom keys, then you might want to backup any existing keys first, so that you can selectively restore them if you wish.

According to the Secure Boot specification, if the PK is cleared, Secure Boot will be in so-called Setup Mode, which allows free editing of all key sets and unrestricted booting. So, ideally, you want to just remove the PK but leave the other keys as-is for now.

Best case, this allows editing of Secure Boot keys from within a UEFI-aware OS using appropriate tools; worst case, you need to use the UEFI Shell and the keytool.efi utility from James Bottomley's efitools package.

Your end goal should probably be something like this:

• the db set should contain:
  • your own public key certificate, for booting things you've explicitly signed
  • maybe your favorite Linux distribution's kernel signing certificate, if you want to use pre-packaged kernels without manually re-signing them
  • maybe hardware vendor's certificate, to allow installing firmware updates if necessary
  • maybe Microsoft's third-party UEFI certificate, to allow the use of pre-packaged Linux bootloaders and live Linux boot media without explicitly re-signing them or disabling Secure Boot
  • maybe Microsoft's OS signing certificate, if you dual-boot with Windows
• the KEK set should contain:
  • your own certificate, for updating db and dbx
  • if your system includes UEFI-aware Microsoft OSs, you may want to include Microsoft's KEK certificate, as Microsoft's updates sometimes include updates to db and/or dbx and those updates won't install successfully if access to Secure Boot is denied
• and finally, once all the rest is set up as you want, you should place your own certificate into PK to make Secure Boot effective again.

Answer 2

This section of Sakaki's EFI install guide shows how you can install keys to authenticate your self-signed kernels with. The whole guide is made for Gentoo, but most of this section can be adapted for use on all OSs and it also explains how it works.

Answer 3

Have a look at these articles:

• Managing EFI Boot Loaders for Linux
• Controlling Secure Boot

and maybe this too:

• UEFI SecureBoot mini-HOWTO