[personal profile] mjg59
The 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.

Distributions are then able to take an existing signed copy of shim and put it on their install media, along with a file containing their key. If a user attempts to boot then the boot will fail because the second stage bootloader isn't signed with a trusted key, but the user can then use the navigator and select the distribution's key file. After providing confirmation and rebooting, the second stage bootloader's signature will now be recognised and the installer will boot.

This has the advantage over the first two options that the UI is consistent, making it easier to document the install process. The primary disadvantage is that the distribution won't be able to rebuild shim and will have to ship a pre-compiled binary. This may well be unacceptable to distributions like Debian, but should still provide a viable approach for other distributions who are either unwilling or unable to deal with Microsoft themselves.
Identity URL: 
Account name:
If you don't have an account you can create one now.
HTML doesn't work in the subject.


If you are unable to use this captcha for any reason, please contact us by email at support@dreamwidth.org

Notice: This account is set to log the IP addresses of everyone who comments.
Links will be displayed as unclickable URLs to help prevent spam.


Matthew Garrett

About Matthew

Power management, mobile and firmware developer on Linux. Security developer at Nebula. Ex-biologist. @mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer.

Expand Cut Tags

No cut tags