Search My Blog

Monday, December 31, 2012

Secure Boot Bootloader for Linux Distributions Available Now

I've been waiting and hoping for this to happen for about a year now. So, this is very good news to me. I've been running Fedora and Debian Linux as my main OS's since 2005. As well as many other Rescue Linux Distros. When I work on Restoring broken Windows Systems and Data Recovery, etc. And I sure didn't want to be stuck using Old Hardware, Forever! Or have to change to a Linux Distro, that I rally don't care for (Ubuntu etc). Fedora has decided to buy keys from Microsoft. So, I'm good there, for now. But, what about all of the other, smaller Linux Distros, that I use??? So, indeed... This is very good news to me!:) I'm a bit behind in finding out. About a month or so. But, that's ok. I'm not quite ready to by that New Hardware yet anyway. Check out and download, mjg59's, Secure Boot bootloader for distributions available now...


mjg59The plan for supporting UEFI Secure Boot in Fedora is still pretty much as originally planned, but it's dependent upon building a binary which has the Fedora key embedded, and then getting that binary signed by Microsoft. Easy enough for us to do, but not necessarily practical for smaller distributions. There's a few possible solutions for them.

  • Require that Secure Boot be disabled

    Not ideal. The UI for doing this is going to vary significantly between machines, making it difficult to document. It also means that the security benefits of Secure Boot are lost.

  • Require that the machine be placed in Setup Mode

    Clearing the enrolled Platform Key results in the system transitioning into Setup Mode, and from then on new keys can be enrolled into the key database until a new Platform Key is enrolled. Distributions could ship an unsigned bootloader that then writes the distribution keys into the database - James Bottomley has an example here. This means that the distribution can still benefit from Secure Boot, but otherwise has the same downside that the UI for doing this will vary between machines.

  • Ship with a signed bootloader that can add keys to its own database

    This is more interesting. Suse's bootloader design involves the bootloader having its own key database, distinct from those provided by the UEFI specification. The bootloader will execute any second stage bootloaders signed with a key in that database. Since the bootloader is in charge of its own key enrolment, the bootloader is free to impose its own policy - including enrolling new keys off a filesystem.

I've taken Suse's code for key management and merged it into my own shim tree with a few changes. The significant difference is a second stage bootloader signed with an untrusted key will cause a UI to appear, rather than simply refusing to boot. This will permit the user to then navigate the available filesystems, choose a key and indicate that they want to enrol it. From then on, the bootloader will trust binaries signed with that key.


mjg59I'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.


Secure Boot bootloader for distributions available now

Matthew Garrett provided an overview of his UEFI Secure Boot "shim" workaround - Google Search
mjg59 | Secure Boot bootloader for distributions available now
Shimming your way to Linux on Windows 8 PCs | ZDNet
Index of /~mjg59/shim-signed
mjg59 | Handling UEFI Secure Boot in smaller distributions

No comments: