![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
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.
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.
- 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 profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
Remove Microsoft/other keys from shim?
Date: 2012-10-07 11:53 pm (UTC)Re: Remove Microsoft/other keys from shim?
Date: 2012-10-08 12:15 am (UTC)Re: Remove Microsoft/other keys from shim?
Date: 2012-10-08 09:13 am (UTC)There is still a fundamental problem here!
Date: 2012-10-08 10:54 am (UTC)If there is no way for a user to disable Secure Boot then they are entirely at the mercy of Microsoft in even being able to start their computers. This is monopolistic practice at its worst and should be fought strongly.
Thanks
Date: 2012-10-08 11:57 am (UTC)-Andrew, Fuduntu
UEFI secure boot won't work
Date: 2012-10-08 01:28 pm (UTC)And should the Linux community build an completely open source computer, without restrictions like these?
Re: UEFI secure boot won't work
Date: 2012-10-08 01:43 pm (UTC)Citation needed.
Re: Remove Microsoft/other keys from shim?
Date: 2012-10-08 02:09 pm (UTC)Re: Remove Microsoft/other keys from shim?
Date: 2012-10-08 02:19 pm (UTC)Re: UEFI secure boot won't work
Date: 2012-10-08 03:01 pm (UTC)BIOSes will not bother having working key update or blacklist mechanisms that work via Windows Update, and approximately nobody updates their BIOS. It'll take very little time to find a security hole in some Secure-Boot-signed software and use it as a bootloader for arbitrary malware. If we get very lucky, it'll happen via holes in Windows, Tiano, or other proprietary software, and thus won't cause a pile of bad press for FOSS.
Re: UEFI secure boot won't work
Date: 2012-10-08 03:04 pm (UTC)It's impossible to implement the specification without having that.
no subject
Date: 2012-10-08 03:33 pm (UTC)Re: UEFI secure boot won't work
Date: 2012-10-08 05:04 pm (UTC)Re: UEFI secure boot won't work
Date: 2012-10-08 05:09 pm (UTC)no subject
Date: 2012-10-08 05:19 pm (UTC)Re: UEFI secure boot won't work
Date: 2012-10-08 05:41 pm (UTC)Re: UEFI secure boot won't work
Date: 2012-10-08 05:43 pm (UTC)no subject
Date: 2012-10-08 07:57 pm (UTC)no subject
Date: 2012-10-08 08:18 pm (UTC)Why?
Date: 2012-10-08 09:55 pm (UTC)This is great news for Very Small Or Even Ultimately Tiny Distributions. If I can also load Nvidia drivers I will stop bitching about secure boot.
I'll start again if Microsoft won't sign, it will blacklist it immediately, firmware will include some unexpected stuff...
Re: Remove Microsoft/other keys from shim?
Date: 2012-10-09 12:49 am (UTC)-adamw
Re: There is still a fundamental problem here!
Date: 2012-10-09 12:50 am (UTC)The answer is very simple: no-one else wants to do it. Microsoft has done nothing to stop anyone else acting as a signing authority. No-one else has expressed any interest in being one. Or at least, not a public one. I guess Apple might implement SB and self-sign their own stuff. Who knows, they're Apple.
What about revokation?
Date: 2012-10-09 08:00 am (UTC)no subject
Date: 2012-10-09 11:49 am (UTC)no subject
Date: 2012-10-09 12:03 pm (UTC)