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 bootloadersdbx 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
It depends on how you are installing grub. And of course, if you are installing it on the EFI System Partition (ESP), then it depends on where you are mounting that. In the particular case of your script, it looks as though perhaps it is expecting the ESP to be mounted on /boot/efi, and the /EFI/redhat directory is set up to contain what would ordinarily be in /boot on a BIOS based system. If this is correct, just take the location of grub2.conf on a BIOS system and replace the /boot prefix with /boot/efi/EFI/redhat, and you have your answer, namely /boot/efi/EFI/redhat/grub2/grub2.conf. (Note that /etc/default/grub will not move, because that is only used to generate the grub configuration and not used at boot time.)
There are at least two other common ways of setting up your ESP. One is to mount the ESP directly on /boot. The advantage is that you can then install things like grub and the kernel without worrying about the BIOS/UEFI distinction. The disadvantage is that you are now polluting the root directory of your ESP (which in theory is OS-independent) with all kinds of linux-specific files, like the kernel, whereas it would be tidier to stick all of those in one place like under /EFI/redhat.
The approach I favor (and this is just my opinion), is to mount your ESP on its own directory (/esp), and then bind-mount a subdirectory of your ESP onto /boot. So then you get the advantage of a tidy ESP and the advantage of existing tools finding what they want in /boot. The disadvantages are a slightly more complicated fstab and the fact that you cannot have symbolic links in /boot (a FAT file system). Here is a snippet of an /etc/fstab file on a machine with this setup: