FOG Secure Boot with Shim

[KMEH]

Hi Everyone!

As part of a network migration at my job we’ve been moving towards FOG. Not satisfied with the advice of “just turn secure boot off and on again” and not wanting to mess around with trying to convince a variety of different UEFI implementations to take my custom key, I decided to instead try and hack something together with rhboot’s shim to try and get this to work. And I’m happy to report I’ve managed to get my setup working on most of our computers, with only a minority refusing to work (most of the problems being caused by Dell).

I figured this would be of interest to some people here as I see that Secure Boot is an often asked about topic, and the current solutions aren’t brilliant. While there is a project called foguefi which uses grub and custom kernel to do a similar thing to this, mine requires fewer modifications to FOG as a whole, and could conceivably be implemented officially, especially if iPXE ever managed to get their shim signed by Microsoft.

This guide will do into a bit of detail, so first off I’ll explain how the whole process works, and what this looks like to a Technician who is using fog. However feel free to skip to the guide below.

What is Shim?

The main problem that projects like fog face with implementing Secure Boot is that you must have Microsoft signed binaries. This however poses a problem for open source software, particularly Linux distros. Getting binaries signed by Microsoft is a lengthy, expensive and often impractical thing to do for every Linux distro every time the kernel or grub updates. As such rhboot have created shim.

Like how the name suggests shim is a first stage bootloader designed to be signed by Microsoft making it secure boot compatible and then load a verified binary (such as a Linux Kernel, or even another bootloader), using a combination of MOK (Machine Owner Keys), embedded secure boot keys, and regular Secure Boot keys.

This allows a distro to get one binary signed (the shim) and then sign their bootloaders and kernels themselves. This is the approach used by most major Linux distros. They get a signed shim binary built with their custom secure boot key embedded, and then sign all their binaries with that.

The above approach works really well, except for if you need to modify the kernel after distribution, say if you want to build in an additional driver without updating the kernel. This poses a problem because that means you either have to distribute the certificate and keys you use for signing (which instantly invalidates any protection Secure Boot provides), or you need to find a way to let a user enrol their own Secure Boot keys.

This is where the MOK comes in, if built with it enabled, upon failing to verify the requested binary with an embedded key or an existing secure boot key shim will fallback on another signed binary called mok manager. This binary allows you to enrol your own keys or binaries into your UEFI’s nvram, which shim will check against for a match. This in effect allows you to enrol your keys in a consistent (provided your UEFI implementation is good), device independent way, without ever having to boot into setup.

As a bonus this is exposed at runtime too, so you can use a Linux utility called mokutil to schedule keys to be enrolled next time a shim mok manager combo is booted.

To summarise, this means that to a technician, when network booting a new machine, they will be presented with mok manager, which can then be used to enrol a key, that on next boot will allow the shim to validate the iPXE binary and successfully load it.

Now that the explaining is out of the way, lets get onto setup.

Setting up FOG with Secure Boot via shim

Preparing iPXE for shim

In order to maintain the benefits of secure boot, any secondary bootloader, such as GRUB or iPXE must also somehow verify that the binaries they are loading are correctly signed. In iPXE’s case, by default it simply checks if the binary has a valid matching secure boot key. This poses a problem for our set up as we don’t a valid secure boot key enrolled, only a valid MOK. One solution to this is to load the shim a second time and perform a nested boot.

This has a couple of problems however, due to the way shim works (See this issue if you are interested). To workaround this, the iPXE team have implemented a shim command, that can be used to specify a shim to be loaded and used to validate any binaries called.

This is where our first modification comes in. The version of iPXE built by FOG, lacks the shim command as they have modified a few header files, one of which includes the definition that enables the command. This is reasonably easy to fix however, as you can follow the FOG guide for rebuilding iPXE yourself, however before you actually build it simply add the following line to the general.h file.

#define SHIM_CMD		/* EFI shim command (or dummy command) */

Once added and binaries you build will have the shim command enabled.

Alternatively you could try using an official iPXE build, which has these commands enabled by default. I haven’t tried this, but can’t think of a reason it wouldn’t work. Regardless your mileage may vary. This also will change a step later on, but I’ll mention that when we get to it.

Obtaining a shim

Now for the next step. We need a Microsoft signed shim. I’m not going to provide one directly here, but they’re fairly easy to obtain. Most major linux distros (rhel, Fedora, Ubuntu, Debian etc) have one, and you can just take theirs, in fact you can probably use the one provided by the distro you’re running fog on.

To get this, you simply need to copy the file to your tftpboot folder. For example on ubuntu you would do something like this:

#You may need to run these commands with sudo
#Copy the shim (you can rename this, this is just the file that most UEFI implementations will boot by default)
cp /boot/efi/EFI/BOOT/BOOTX64.efi /tftpboot
#Copy mok manager (I don't believe you can rename this as shim specifically looks for this filename to boot.
cp /boot/efi/EFI/BOOT/mmx64.efi /tftpboot

It’s important you copy both these files as without mok manager you will be unable to enroll the key at boot. Once they’re copied, you can point your DHCP server towards the file, and then you’re devices will boot the shim, however we need shim to boot our iPXE binary. At the moment it won’t have anything to boot.

By default, most shims are configured to boot grub, generally they do this the same way it boots mok manager. It looks for a file named grubx64.efi, as such if we copy our iPXE binary over to grubx64.efi and will attempt to boot it. However, if you try to boot now, you’ll probably encounter a problem. Although you get to mok manager fine, you have no key to enrol, and your iPXE binary isn’t signed so you’ll never get past mok manager.

Signing your binaries

There are a couple of different ways to do this, however I’ve only used the sbsign tool and a script called mkkeys which there is already an excellent guide for by @george1421 which you can find here.

It’s a little in depth and goes into enrolling these keys in your machine via the UEFI, however you can just follow the guide’s sections on creating the keys and certificates, and on signing your binaries… Remember to sign grubx64.efi as well, as this is the iPXE binary that we will be booting from.

Nesting your shim

Now that we’ve signed our binaries, we’re almost done. There’s one final step. You might recall that iPXE needs to load the shim a second time using the shim command. The easiest way to do this is to modify your default.ipxe script. This script is completely static and not modified by fog, unlike other scripts later on which are modified dynamically. This is very simple to do as you can easily just add the following line anywhere before the script chainloads boot.php!

shim tftp://{fog server ip}/{shim file here}

For example if you are setting this up on a node at 192.168.0.10 and you renamed your shim file to shim.efi you would add the following line.

shim tftp://192.168.0.10/shim.efi

NOTE: If you are using an official build, your iPXE binary will not automatically try to call default.ipxe, but as part of trying to get a shim for iPXE, they have implemented a standard ipxe script themselves called autoexec.ipxe which it will attempt to load on boot. As such you can simply make a copy of your default.ipxe script as autoexec.ipxe

Booting and enrolling keys

Now that the set up is complete, it’s time to boot and enrol your key in a machine to test it out. In order to enrol the keys onto your machine, you will need to place them on a FAT32 formatted USB stick as this is the only file system I am aware of mok manager being able to read.

Once this is done, you can simply network or PXE boot your machine as normal, and when it will first boot into shim and then shim will attempt to load iPXE, but will fail because it can’t a valid key. It will then fallback to mok manager which will load an display a blue simple text menu.

To enrol your key, follow these steps:

• Ensure your USB drive is inserted into an active port.
• Select Enrol key from disk
• Chose the partition on your USB drive from the list (if you didn’t choose a label for the partition, it may appear instead as a PCI device path)
• Navigate to the file on your USB Drive
• Select it and pick Continue.
• Then choose yes, and then finally reboot.

If done correctly on your next boot, the shim will successfully validate your iPXE binary and boot into it. At this point iPXE will configure as normal, load the shim an additional time, and then finally continue to boot your other binaries as normal.

If you’re having trouble following the steps, Ventoy has a good section that walks you through the process of using mok manager, complete with a GIF demonstrating the process. You can find this here.

If you have any questions on this process, feel free to reply and ask away. I’m by no means an expert but I’ll be happy to do my best to help. I’m going to add one final section for FAQs and known issues and workarounds that I’ll fill up as I find them (including a couple of big ones I am aware of from my testing.

Known issues and Workarounds

Dell Machines not loading into iPXE

There appears to be a bug in some dell machines’ UEFI which causes it to pass the network cards boot entry name as a file to be loaded. This is solved in shim 16.0, but as far as I am aware at the time of writing, there are Microsoft signed copies of that version with MOK enabled. Once I am aware that one has been signed, I’ll update this with details.

In the meantime you can workaround this issue by creating the file it expects to be loaded. You can find more details on the issue in general and this workaround on the following links, including a section of the script from the foguefi project that will generate these files for you.

https://github.com/rhboot/shim/issues/649
https://github.com/rhboot/shim/issues/649#issuecomment-2582917049
https://github.com/abotzung/foguefi/blob/main/install.sh#L357

Some Dell machines refuse to enrol keys

Some Dell’s have another UEFI bug which seems to cause mok manager to keys are in valid because they fail the file extension check. I’m not sure why this happens, but it appears to be based on the length and contents of the filename. On the machines I’ve tested with this issue the names “ENROL_THIS_KEY_IN_MOK_MANAGER.cer” which is used by Ventoy, and “TESTING123.cer” which I found, both seem to work fine.

I’m unfortunately not aware of any actual fixes here, as I believe this is an issue with the machine’s UEFI not shim.

FAQs

I currently don’t have anything to put here, I’ll add FAQs as they pop up.

This is my first time posting here as well, I did look around for any rules to follow, but I couldn’t find any. Apologies if I’ve broken any, happy to amend things to comply to any.