[personal profile] mjg59
I've written rather a lot about how we're implementing our Secure Boot support, but there's been a range of subtle changes over time. Here's an overview of how it all fits together.

Secure Boot and signing

Secure Boot is part of the UEFI specification. When enabled, systems will refuse to boot any UEFI executables (such as an OS bootloader) unless they've been signed by a trusted key. The only trusted key effectively guaranteed to be present is Microsoft's, and Microsoft will sign binaries if you have access to the Windows hardware dev center. You gain access to this by purchasing a certificate from Verisign that verifies your identity and then use that to create a developer account at the Sysdev website. Once you've agreed to the legal contracts, you can submit a UEFI executable and Microsoft will then send you back a signed one. The signature is added to the end of the binary, so it's trivial to verify that your executable hasn't otherwise been modified in the process.

Avoiding signing round trips

We didn't want to have to get binaries re-signed every time we updated our bootloader or kernel, so we came up with a compromise approach. We implemented a shim bootloader (cunningly called "Shim") which is signed by Microsoft and includes a copy of a public key that's under our control. Shim will launch any binary signed with either a key installed in the system firmware or the public key built into it. This allows us to build and sign all other binaries ourselves.

Preventing Secure Boot circumvention

Secure Boot is intended to prevent scenarios where untrusted code can be run before an OS kernel. Locking down the boot environment avoids the simple case of using a modified bootloader, and requiring that the kernel also be signed avoids simply booting arbitrary attack code that looks roughly like a kernel but does nothing to prevent the more complex case of using a running kernel to launch another kernel. To do that we've had to restrict the behaviour of the kernel in Secure Boot environments. Direct hardware access from userspace has been blocked, and modules must be signed by a key the kernel trusts.

Providing user control over trust

Microsoft requires that it be possible to modify the key database on all Windows-certified x86 systems, but the UI to do so may be inconsistent and awkward. Suse developed a plan to avoid this, involving adding an additional key database to the system. The user enrols a key from the running OS and enters a password. On the next reboot, shim detects that a key is awaiting enrolment and drops to a prompt. If the user does nothing or just hits enter, the system continues to boot. If the user chooses to enrol a new key, the user is asked to re-enter the password in order to confirm that they're the same user that initiated the original request. If successful, the key is then copied into a boot services variable which cannot be directly modified from the OS. Anything signed with the user's key will then be trusted.

Providing user control over signature verification

Some users (such as kernel developers) may be hampered by Secure Boot - forcing them to sign every new kernel they build is time consuming and unhelpful. Windows-certified x86 hardware will be required to provide an option to disable Secure Boot, but again that UI may be inconsistent. We've added an option where a user can generate a request to disable signature validation, again requiring a password. On next boot the user must explicitly choose the "Toggle signature validation" menu item and will then be requested to enter three randomly chosen characters from their password. After confirmation, signature validation in Shim will then be disabled.

Supporting other distributions

Not all distributions will want (or be able) to sign via Microsoft. They'll be able to take any other signed version of Shim and put it on their boot media. If their second stage bootloader is signed by a key that Shim doesn't trust, Shim will pop up a menu permitting the user to choose to enrol a new key off the install media. The user can select this, navigate a file browser and select the key. After confirmation, the key will be added to Shim's trusted key list. The user can then install the distribution.

Third party modules

There's two approaches here. The first is for the third party to provide a module key that the user can install into Shim's database. The kernel will import this at boot time and trust any modules signed with it. The second is for the third party to provide a key signed by Microsoft. David Howells has come up with with the idea of utilising this approach of embedding a public key in a pe binary, with the kernel then having support for importing this key, noticing that it's signed by a trusted key and adding it to the kernel keyring.

How about ARM?

We're not planning on supporting Secure Boot on ARM, for two reasons. The first is that Microsoft require that it be impossible to disable Secure Boot on ARM, and we don't want to support systems unless it's guaranteed that the user will be able to run what they want. The second is that there's no strong expectation that the signing key used for signing third party UEFI binaries will be present on ARM systems.

What are other distributions doing?

As far as I know, Suse and Fedora will be shipping the same code. Ubuntu is shipping an older version of Shim but should pick up the local key management code in the next release. The only significant difference is that Ubuntu doesn't require that kernel modules be signed.

Dynamic trusted root

Date: 2012-10-30 07:49 pm (UTC)
From: (Anonymous)
I am wondering: why is everyone putting so much energy into making secure boot with static root explainable and usable, when we could avoid most of all those problems with dynamic trusted root?

Re: Dynamic trusted root

Date: 2012-10-30 07:52 pm (UTC)
From: (Anonymous)
Sure there is, just look at Intel txt and tboot for example.

Re: Dynamic trusted root

Date: 2012-10-30 08:12 pm (UTC)
From: (Anonymous)
True, but again, it was an example. AMDs and ARMs TrustZone are the same thing.
As for the specific chipset required, that's also true for secure boot in general.

Re: Dynamic trusted root

Date: 2012-11-01 12:52 am (UTC)
From: (Anonymous)
how can the firmware protect all the key data without chipset support?

Re: Dynamic trusted root

Date: 2012-11-01 03:02 pm (UTC)
From: (Anonymous)
protect from say the OS kernel or equivalent code in an attack scenario. i.e., think pure software attacks (i think that's what this whole 'prevent rookits from taking over early boot' is all about in Secure Boot). so how can the firwmare without chipset support prevent said kernel/etc code from playing with the Secure Boot keys/etc? because if it cannot, then this exercise was all in vain, and if it can, there must be chipset level support for it. which is it? ;)

Re: Dynamic trusted root

Date: 2012-11-03 08:30 pm (UTC)
From: (Anonymous)
how is the flash protected? does that protection rely on chipset support?

Re: Dynamic trusted root

Date: 2012-11-04 12:53 am (UTC)
From: (Anonymous)
i see, so we're quite far from your original 'Secure Boot has no chipset requirements' since it's the chipset that has recognize transactions initiated from SMM ;). now coming back to the original poster's question, how's Secure Boot safer/better/etc than what we can get with TXT? you also said there's no specification for TXT, but then i can boot my systems with tboot just fine. so where's the problem? also Secure Boot's reliance on trusting SMM leaves one with a certain uneasiness given the attacks people have presented over the past few years...

Re: Dynamic trusted root

Date: 2012-11-04 06:28 pm (UTC)
From: (Anonymous)
(U)EFI is an Intel-specific specification (in case you haven't been around for that long, they started EFI in the late 90's, the spec used to be 'Intel Confidential' for a number of years). so is the chipset support required for Secure Boot. now back to my question one more time: how's Secure Boot safer/better/etc than what we can get with TXT?

Re: Dynamic trusted root

Date: 2012-11-05 12:41 am (UTC)
From: (Anonymous)
you already figured out that Secure Boot needs chipset support. that implies that support for Secure Boot *is* tied to a specific chipset vendor, in our case Intel because it's pretty much Intel who produces chipsets for their own CPUs. if you wanted to have Secure Boot with AMD or ARM CPUs then you wouldn't get far with Intel chipsets, would you? on the other hand AMD also has SKINIT. so it seems we're back to square one: why's Secure Boot better than TXT? being vendor specific is not it.

Date: 2012-10-31 05:28 am (UTC)
From: (Anonymous)
"The only significant difference is that Ubuntu doesn't require that kernel modules be signed."

If the Microsoft signed key allows a kernel to be loaded that effectively allows secure boot to be bypassed via a module, why wouldn't they revoke the key in the same way that a shim that allows an untrusted kernel to be loaded?

Date: 2012-10-31 04:14 pm (UTC)
From: [identity profile] pjones.id.fedoraproject.org
They will, but not until it's actually used that way. Somebody's trying to make a show.

Profile

Matthew Garrett

About Matthew

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

Page Summary

Expand Cut Tags

No cut tags