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.
Best Answer
I found the problem. Looking at the NVRAM with
sudo efibootmgr
I noticed that the Windows boot loader somehow seems to have the urge to be the first entry in the boot order. When I changed it to grub2 being first, windows overwrites entry 0000 and changes the boot order, even if grub2 was 0000 before, therefore overwriting it.The solution was setting the Windows boot manager entry inactive but leave it in first position of the boot order:
sudo efibootmgr --bootnum 0000 --inactive sudo efibootmgr --bootorder 0000,0002,000C,000D
(with 0002 being grub2)