1

I am writing my own OS loader (Boot Loader) in UEFI. The OS Loader is Microsoft Signed so it can run under secure-boot. The OS Loader will be able to load Windows or Linux Kernel based on User's Selection (Something similar to GRUB) Since I have built Linux Kernel as EFI Stub, I can load it from my OS Loader.

However, I have a specific requirement. I will be self-signing the Linux Kernel.

How do I establish chain of trust to make sure that I am loading my own self-signed Linux Kernel and not some other unsigned kernel?

Edited on 21-Jan-2022 after working on suggestions from telcoM

Continuing from the answer from telcoM, I downloaded SHIM source from https://github.com/rhboot/shim
I also created PKI keys following
https://www.rodsbooks.com/efi-bootloaders/secureboot.html#initial_shim

$ openssl req -new -x509 -newkey rsa:2048 -keyout MOK.key -out MOK.crt -nodes -days 3650 -subj "/CN=Your Name/"
$ openssl x509 -in MOK.crt -out MOK.cer -outform DER

Built SHIM source using

make VENDOR_CERT_FILE=MOK.cer

Signed my kernel.efi with MOK.key to get signed grubx64.efi (This is because DEFAULT LOADER in SHIM is grubx64.efi. I just went ahead with defaults)

sbsign --key MOK.key --cert MOK.crt --output grubx64.efi  kernel.efi

Finally, used shimx64.efi as loader.efi (using PreLoader https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/) because at present I don't have shimx64.efi signed by Microsoft. In addition, mmx64.efi and fbx64.efi are also enrolled through HashTool.efi along with shimx64.efi (loader.efi)

Here is the flow.
PreLoader.efi --> loader.efi(shimx64.efi) --> grubx64.efi(kernel.efi)

With SecureBoot disabled, everything works fine and I am able to boot Linux Kernel.
However, with SecureBoot enabled, I am not able to start grubx64.efi image.

Further updates

I figured out that I should have used MokManager (mmx64.efi) to enroll MOK.cer. Tried using mmx64.efi and enrolled MOK.cer. However, it looks like the Key is not registered successfully.

Am I missing anything?

Improve this question
3
  • Sorry for asking, but how did you manage to get your OS loader signed by Microsoft?
    – Alex Baranowski
    Commented Jan 14, 2022 at 9:35
  • Well not yet. It is just a thought that Microsoft will sign it.
    – NJP
    Commented Jan 14, 2022 at 9:38
  • Well. It might be a little bit harder than you initially thought. Generally speaking, getting anything signed from Microsoft require quite a lot, and it's a good thing. It's pretty easy to compromise the whole secure boot idea by leaking a key [many people don't patch their firmware very often]. You can look at the Linux distros that are trying to get a secure boot key for their shims/grubs/kernels at the - github.com/rhboot/shim-review/issues
    – Alex Baranowski
    Commented Jan 14, 2022 at 10:06

2 Answers 2

Reset to default
3

Your OS Loader needs to include a copy of the public part (a.k.a. the certificate) of the key you'll be using to sign your own kernel. Any time that key changes, you will need to have your OS Loader re-signed by Microsoft.

You might want to study the source code of the shimx64.efi Secure Boot shim bootloader that is used by many major distributions to handle Secure Boot:

https://github.com/rhboot/shim

Alternatively, you would have to get a copy of the public part of your kernel signing key added to the db UEFI NVRAM variable. Normally this is only possible if you replace the Secure Boot primary key (PK UEFI NVRAM variable) on your system. It depends on your system's firmware implementation how (or indeed if) this can be done.

Common possible ways:

  1. If your UEFI firmware settings ("BIOS settings") include a way to directly edit the Secure Boot keystores, that could be used to add your kernel signing key directly to the db variable. You might have to reset or replace the PK primary key first, see below.

  2. If your UEFI firmware settings don't include a way to directly edit Secure Boot keystores, but include a way to zero out the PK primary key of Secure Boot, this can be enough to get you started. Zeroing out the PK places Secure Boot in Secure Boot Setup Mode, in which any kernel can be booted and all Secure Boot keystores can be edited. Setup Mode ends when a new Secure Boot primary key (i.e. a digital certificate similar to what is used in signing kernels for Secure Boot) is stored into the PK keystore variable.

While in Secure Boot Setup Mode, all the Secure Boot keystores should be editable by OS-level programs, like efivar https://github.com/vathpela/efivar.git or sbsigntools https://git.kernel.org/pub/scm/linux/kernel/git/jejb/sbsigntools.git for example. In practice this does not always work; it depends on the properties of the UEFI implementation in your system's specific firmware.

If your firmware does not allow editing Secure Boot keystores by OS-level programs, you might have better luck by using a UEFI-mode tool, like KeyTool.efi from the efitools package: https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git

(It is possible to protect UEFI NVRAM variables so that they are only accessible to boot-time .efi programs, not by the regular OS; I've seen some UEFI implementations that seem to restrict the Secure Boot keystores in this way, although the Secure Boot specification does not require that.)

Improve this answer
1
  • This is great information. I am going through the RedHat's SHIM source code. What I have understood till now is that the SHIM does all the magic by relocating .efi application which it is going to execute.
    – NJP
    Commented Jan 17, 2022 at 10:17
1

For secure boot, you can add your key to the "machine owner key" keybase. The Scientific Linux used to do it with the following commands.

cd /tmp
curl http://cacerts.digicert.com/DigiCertHighAssuranceEVRootCA.crt | openssl x509 -inform der  > DigiCertEVCodeSign.pem
curl http://cacerts.digicert.com/DigiCertEVCodeSigningCA-SHA2.crt  | openssl x509 -inform der >> DigiCertEVCodeSign.pem
curl http://ftp.scientificlinux.org/linux/scientific/7x/x86_64/os/SECURE-BOOT-KEY-fnal-sl7-exp-2023-09-27 | openssl x509 -inform der > SECURE-BOOT-KEY-fnal-sl7-exp-2023-09-27.pem
curl http://ftp.scientificlinux.org/linux/scientific/7x/x86_64/os/SECURE-BOOT-KEY-fnal-sl7-exp-2020-08-26 | openssl x509 -inform der > SECURE-BOOT-KEY-fnal-sl7-exp-2020-08-26.pem
curl http://ftp.scientificlinux.org/linux/scientific/7x/x86_64/os/SECURE-BOOT-KEY-fnal-sl7-exp-2017-07-26 | openssl x509 -inform der > SECURE-BOOT-KEY-fnal-sl7-exp-2017-07-26.pem

certtool -V --verify --load-ca-certificate=DigiCertEVCodeSign.pem --infile=SECURE-BOOT-KEY-fnal-sl7-exp-2023-09-27.pem
certtool -V --verify --load-ca-certificate=DigiCertEVCodeSign.pem --infile=SECURE-BOOT-KEY-fnal-sl7-exp-2020-08-26.pem
certtool -V --verify --load-ca-certificate=DigiCertEVCodeSign.pem --infile=SECURE-BOOT-KEY-fnal-sl7-exp-2017-07-26.pem
# use mokutil to import 
mokutil --import /etc/pki/secure-boot/SECURE-BOOT-KEY-fnal-sl7-exp-2023-09-27

The command reponsible for manipulating machine owner keybase is mokutil.

Source: http://ftp.scientificlinux.org/linux/scientific/7.9/x86_64/release-notes/#_about_uefi_secure_boot

Improve this answer
3
  • Is there any equivalent of mokutil in Windows?
    – NJP
    Commented Jan 14, 2022 at 9:40
  • I tried google-fu, and I haven't found anything useful. You can always do the following: - Generate the key on Windows (or Linux) - Boot some live distro version that supports secure boot (from USB) like Ubuntu Live - Import your key with mokutil
    – Alex Baranowski
    Commented Jan 14, 2022 at 10:08
  • 1
    Note that the Machine Owner’s Key keybase is introduced by the shimx64.efi. Without it, the MOK keybase is just another UEFI NVRAM variable with no particular effect to Secure Boot.
    – telcoM
    Commented Jan 17, 2022 at 11:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .