Secure Boot bootloader for distributions available now

[mjg59]

I'm pleased to say that a usable version of shim is now available for download. As I discussed here, this is intended for distributions that want to support secure boot but don't want to deal with Microsoft. To use it, rename shim.efi to bootx64.efi and put it in /EFI/BOOT on your UEFI install media. Drop MokManager.efi in there as well. Finally, make sure your bootloader binary is called grubx64.efi and put it in the same directory.

Now generate a certificate and put the public half as a binary DER file somewhere on your install media. On boot, the end-user will be prompted with a 10-second countdown and a menu. Choose "Enroll key from disk" and then browse the filesystem to select the key and follow the enrolment prompts. Any bootloader signed with that key will then be trusted by shim, so you probably want to make sure that your grubx64.efi image is signed with it.

If you want, you're then free to impose any level of additional signing restrictions - it's entirely possible to use this signing as the basis of a complete chain of trust, including kernel lockdowns and signed module loading. However, since the end-user has explicitly indicated that they trust your code, you're under no obligation to do so. You should make it clear to your users what level of trust they'll be able to place in their system after installing your key, if only to allow them to make an informed decision about whether they want to or not.

This binary does not contain any built-in distribution certificates. It does contain a certificate that was generated at build time and used to sign MokManager - you'll need to accept my assurance that the private key was deleted immediately after the build was completed. Other than that, it will only trust any keys that are either present in the system db or installed by the end user.

A couple of final notes: As of 17:00 EST today, I am officially (rather than merely effectively) no longer employed by Red Hat, and this binary is being provided by me rather than them, so don't ask them questions about it. Special thanks to everyone at Suse who came up with the MOK concept and did most of the implementation work - without them, this would have been impossible. Thanks also to Peter Jones for his work on debugging and writing a signing tool, and everyone else at Red Hat who contributed valuable review feedback.

Comments

[(Anonymous)]

My bootloader boots fine, but when I it tries to load vmlinuz it says access denied.

I've signed both the bootloader and vmlinuz with the exact same certificate and the same tool, and enroled the key to the database. What's going on?

[(Anonymous)]

I'm using Gummiboot for my bootmanager, by the way.

[mjg59]

Oh, right. gummiboot just calls LoadImage() and StartImage(). That won't work unless the signing certificate is enrolled in db - it won't use the Mok database.

[(Anonymous)]

So does that mean distros are stuck using GRUB or rEFInd until Gummiboot and Syslinux provide decent EFI support?

[(Anonymous)]

No. The issue is with follow-on boot programs from shim that load EFI executables. Currently, rEFInd and gummiboot both launch Linux kernels in this way, using the kernel's EFI stub loader to load and launch the kernel as an EFI application. (So does rEFIt, but it can't pass arguments, so it's very awkward in this role.) GRUB Legacy, GRUB 2, and ELILO all launch kernels without relying on their EFI stub loaders or the EFI system calls that are used to launch EFI applications. Therefore, if you sign one of these boot loaders, it can launch anything. The downside to this is that the commonly-available boot loader binaries don't verify that a kernel has been signed. The Fedora 18 pre-release archives include a version of GRUB 2 that performs such checks, but if anybody's done anything with GRUB Legacy or ELILO that's similar, I don't know about it. The last I checked, Syslinux wasn't an issue because there was no Syslinux EFI support, although I heard the Syslinux people were working on it.

So in summary, shim->F18 GRUB2->kernel and shim->rEFInd 0.5.0->kernel both now provide authenticated boot paths; shim->kernel could in principle be authenticated, but this will depend on getting a patched shim signed; shim->GRUB Legacy->kernel and shim->ELILO->kernel both provide an unauthenticated boot path; and shim->gummiboot->kernel won't work in Secure Boot mode unless/until gummiboot adds shim support. (Note that I've not tried launching either GRUB Legacy or ELILO directly from shim, so I can't be sure those paths will actually work.)

[(Anonymous)]

Some of us don't have any interest in using a Microsoft signed shim. For those of us willing to place our distribution's keys in the firmware, will using GRUB2 (Fedora's package, until GRUB2 includes secure boot support in upstream) standalone still work? Or is it impossible to provide an authenticated pathway this way?

[mjg59]

Fedora's grub2 currently calls back into shim in order to perform the key validation, since otherwise the code would need to exist in both. The easiest thing to do is just to use shim, but sign it yourself.

[(Anonymous)]

If you want to guarantee that you load a signed (but not an unsigned) kernel, then AFAIK you've got six options right now:

* shim->F18's GRUB2->kernel
* shim->rEFInd 0.5.0->kernel
* Patched shim->kernel
* Any rEFInd->kernel
* gummiboot->kernel
* kernel direct (via EFI boot manager)

These all assume that you sign the first item launched with the Secure Boot keys you generate, and the last three also require that you sign your kernel with the same keys. The first three will launch kernels signed with whatever keys are built into shim or supported by MOKs you've loaded into your firmware. All but the first require a 3.3.0 or later kernel with EFI stub support. Since you're replacing your firmware's MS keys, IMHO there's not much point to the shim->rEFInd->kernel and patched shim->kernel paths; shim doesn't add anything to either path.

GRUB 2 does support chainloading another EFI boot loader. If it does so using standard EFI system calls, in theory a GRUB2->kernel path would work *if* you launch the kernel via GRUB2's "chainloader" command rather than the "linux" command and if your kernel is 3.3.0 or later with EFI stub support. My one attempt (months ago) to do this without Secure Boot failed, but I never tried to track down what went wrong; it could have been a simple typo in my configuration file. If this could be made to work, though, it might provide a seventh option that would work exactly as you want it to.

[(Anonymous)]

Or, er, rather, in Gummiboot's case, proper shim support.

[mjg59]

If you want to use gummiboot with Shim's key implementation, then gummiboot needs to be aware of Shim. The alternative is for gummiboot to load, relocate and execute binaries itself.

[mjg59]

Difficult to know. Can you precisely describe what you did?

[(Anonymous)]

There's a bug in shim that prevents it from loading a Linux kernel; it's a bit too strict in its checks for relocation information. The Linux kernel lacks EFI stub relocation information but loads just fine if the bulk of the relocation function is skipped. (This is what an actual EFI implementation does if the kernel is signed with a regular Secure Boot key.) Also, any post-shim boot manager that uses standard EFI calls to launch a boot loader must call back to shim and jump through some extra hoops, since the standard EFI calls don't "talk" to shim themselves. AFAIK, gummiboot doesn't yet do this. My own rEFInd (http://www.rodsbooks.com/refind/) does, as of version 0.5.0.

[(Anonymous)]

I was about to hunt down your boot manager, as a matter of fact. I don't mean this in a bad way (because I really do appreciate your work) but you do advertise yourself quite often. ;)

[(Anonymous)]

To expand on this, here's a patch that fixes the problem with shim being unable to load a Linux kernel:

http://www.rodsbooks.com/shim.patch

FWIW, I "borrowed" a few shim functions for rEFInd 0.5.0, and I incorporated this patch in my version of relocate_coff(). Feel free to use it in future versions of shim.

[mjg59]

Hm. Yeah, I hadn't considered that case - thanks, I'll merge something like that.