Matthew Garrett

Ubuntu ODM UEFI requirements for secure boot

A couple of people have asked me about the Ubuntu ODM UEFI requirements, specifically the secure boot section. This is aimed at hardware vendors who explicitly want to support Ubuntu, so it's not necessarily the approach Canonical will be taking for installing Ubuntu on average consumer hardware. But it's still worth looking at.

In a nutshell, the requirements for secure boot are:

The system must have an Ubuntu key preinstalled in each of KEK and db

It must be possible to disable secure boot

It must be possible for the end user to reconfigure keys

It's basically the same set of requirements as Microsoft have, except with an Ubuntu key instead of a Microsoft one.

The significant difference between the Ubuntu approach and the Microsoft approach is that there's no indication that Canonical will be offering any kind of signing service. A system carrying only the Ubuntu signing key will conform to these requirements and may be certified by Canonical, but will not boot any OS other than Ubuntu unless the user disables secure boot or imports their own key database. That is, a certified Ubuntu system may be more locked down than a certified Windows 8 system.

(Practically speaking this probably isn't an issue for desktops, because you'll need to carry the Microsoft key in order to validate drivers on any PCI cards. But laptops are unlikely to run external option ROMs, so mobile hardware would be viable with only the Ubuntu key)

There's two obvious solutions for this:

Canonical could offer a signing service. Expensive and awkward, but obviously achievable. However, this isn't a great solution. The Authenticode format used for secure boot signing only permits a single signature. Anything signed with the Ubuntu key cannot also be signed with any other key. So if, say, Fedora wanted to install on these systems without disabling secure boot first, you'd need to have two sets of install media - one signed with the Ubuntu key for Ubuntu hardware, one signed with the Microsoft key for Windows hardware.

Require that ODMs include the Microsoft key as well as the Ubuntu key. This maintains compatibility with other operating systems.

This kind of problem is why we didn't argue for a Fedora-specific signing key. While it would have avoided a dependence on Microsoft, it would have created an entirely different kind of vendor lock-in.

Update: Canonical have now provided their full plans. They won't be providing a signing service, but will be requiring that all Ubuntu-certified hardware ship with the Microsoft key

I don't think you missed anything: some of Ubuntu's requirements are explicitly conditional on the enablement of Secure Boot, which (along with a lack of indication that it's compulsory) suggests that it can be shipped disabled. This is of course a second difference from Microsoft's approach.

This is one of several solutions competing to be the least-worst option. I truely can understand why Canonical don't want their OEM pre-installed systems to be signed with a Microsoft key, or to compel OEMs to carry the Microsoft key (I think it is still an option for the OEMs to do so and I am fairly certain they will unless Microsoft prevent them). Depending on what Canonical do for the regular aftermarket CD this might make it equally tricky to install an Ubuntu CD on these computers as it would be for any other distribution.

If Google decided to do what Canonical did.. avoiding MS as a signing service.. that will really bring home the limitation inherent in the single allowed signature on driver blobs. Microsoft and Google standing themselves as different signatories for drivers is going to mean double the work. for all mobile device manufacturers. No offense to Canonical but they aren't one of the 500 lb gorillas and unfriendly vendors will just ignore Canonical's requirements. Nobody in the ARMs-race can ignore Google. And as gross as this issue is on intel "PC" hardware the real fight is going to be ARM as MS tries to muscle in and lockin there.

As I understand this issue, Microsoft rather coyly does not in fact include this (ie. a requirement that the user (owner) be able to manage Secure Boot keys in their UEFI) in the Windows certification requirements -- which is the substantial basis for it being an issue in the first place.

If the user can reliably manage keys in the UEFI (or even just "reconfigure" "a" key, which would be less satisfactory but not really horribly broken), then doesn't the fundamental problem go away?

Ubuntu wouldn't need to supply a signing service, because users could sign their own software (or maybe even use some key supplied by some other particular distro -- even one from Fedora or Red Hat).

Of course, Microsoft is already insisting that Windows-certified ARM hardware shall not permit key management or even disabling Secure Boot.

I don't consider an "option to disable" to qualify as "ability to manage" (ie. add, remove, possibly even blacklist keys). I suspect you don't, either.

Has Microsoft changed their Secure Boot (x86) requirements once again, so as to not only require that disabling Secure Boot is a user option, but to also require such key management be be available to the user?

I haven't heard anything about it -- which is a little surprising, considering that this was the big problem that everyone was upset about.

PS: I just took a quick look at the Ubuntu document you linked:

Any machine shipped with Ubuntu must support reconfiguration of the keys used in the secure boot process, to allow users to use secure boot with their own keys and custom boot images. The firmware interface should allow a physically-present user to enter the machine in to setup mode, or manually load KEK, db and dbx entries from disk or removable storage. This require-ment is compatible with the Windows 8 Hardware Certification Requirements [WIN8HCR], § System.Fundamentals.Firmware.UEFI SecureBoot, item 20.(page 26)

That does not appear to say that the Ubuntu Certification requirements are the same as Microsoft's Certification requirements, but rather that Ubuntu's additionalrequirement for user-accessible key management features iscompatiblewith Microsoft's Secure Boot specification (which I presume is true, as Microsoft has not yet forbidden user-manageable Secure Boot keys -- at least not for x86 hardware).

I appear to have found the relevant portion of the specification (page 122 of the May 9, 2012 version of Microsoft's Windows Hardware Certification Requirements document -- assuming I actually understand it properly).

This change in the Windows 8 certification requirements appears to have received very little coverage in the popular tech press (certainly a lot less than the previous concerns that those requirements would effectively undermine sensible, OS-neutral implementations). I have heard nothing about this in my regular on-line haunts -- and it appears that I am not the only one.

I suppose I should do some review, and refresh my understanding of the whole matter. As a non-techie Linux-user, all that PKPub, PKPriv and KEK stuff gets easily jumbled -- and now it looks like I might actually have cause to keep the details straight :-P. Ah well -- better that than remain both misinformed and ignorant.

So, good luck getting it all ironed out and practicable! Your work is appreciated.

"""MANDATORY. On non-ARM systems, the platform MUST implement the ability for a physically present user to select between two Secure Boot modes in firmware setup: "Custom" and "Standard". Custom Mode allows for more flexibility as specified in the following:

It shall be possible for a physically present user to use the Custom Mode firmware setup option to modify the contents of the Secure Boot signature databases and the PK. This may be implemented by simply providing the option to clear all Secure Boot databases (PK, KEK, db, dbx) which will put the system into setup mode."""

It looks like some vendors will have the option to be lazy and just allow the secure boot stuff to be cleared -- I don't see where a vendor going that route has to provide a subsequent means to edit the cleared database.

Microsoft says it is mandatory to be able to go into a custom secure boot mode and then they say that the implantation of this custom secure boot mode can simply consist of an option which clears the databases and sends you back to setup mode with secure boot off -- so not really custom mode at all!

This is my biggest concern, that any free operating system that doesn't get involved in the microsoft signing scheme is going to be in a second class position where they can't get the benefit of secure boot. (the hassle of self installing keys is okay for me as long as the option really is there)

I agree with Matthew that secure boot isn't security theatre, so being forced to disable it instead of being able to fully control it and use it for your purposes is a substantially inferior position to be in.

I could live with a crappy firmware that meets this silly description of custom mode if such firmwares also allowed me to take flash my own firmware with my own secure boot implementation. That way I could still get the benefits of secure boot for myself and wouldn't be buying hardware that (in theory) gives one group of operating systems better security than any other.

Somebody tell me that I'm reading this wrong and that the mandatory custom mode for windows 8 certification really does have to live up to its name and must consist of real customizations to stored keys.

I sure hope that enrolling keys is a mandatory aspect of setup mode for Windows 8 certification on non-ARM.

The words setup mode and SetupMode only appear a few times in the Microsoft document (pages 119, 122, 124), and it's never described well there as to what capabilities it does and does not give the user.

So we're relying on transitivity of mandatoryness here? Microsoft has made some aspects of UEFI re setup mode mandatory and those parts of UEFI make it mandatory for setup mode to have this feature?

Transitivity of mandatoryness makes me less confident that the MS certification process will actually produce this outcome in shipped hardware. I'll believe it when I see it.

All I can read into the UEFI re setup mode is that yes, it is intended for this kind of thing. It's hard to find a clear mandate in UEFI that setup mode must include a real user interface for actually putting key changes into practice. The UEFI spec is very API oriented, e.g. "The platform owner enrols the public half of the Platform Key (PKpub) by calling the UEFI Boot Service SetVariable()".

It's hard to appreciate what setup mode will actually entail in terms of relevant user interfaces being when reading the UEFI spec.

It's not going to be fun if code is present in the firmware for changing the platform key but there's not an actual user interface to let you use that code.

But this isn't my nightmare "second class" scenario as long as long as firmware can load your own code and allow you to use the firmware API to change the platform key. (presumably the firmware enters setup mode and stays in setup mode as your code takes over?). It is the extensible firmware interface after all, right?(But we'll still be prevented from installing our own firmware or firmware signing key by the time our own code kicks in, so coreboot is still locked out?)

And, assuming UEFI machines can stay in setup mode (or equivalent) while also loading your own code to take advantage of setup mode, I wonder, will my code be able to come from removable media (cd, hd, USB?) or will I need something like an option ROM to run my own setup mode code to make the UEFI calls for changing the platform key?

A slight ray of hope can be found in section 27.5 of UEFI:"While in setup mode, the platform firmware shall not require authentication in order to modify the Platform Key or the Key Enrolment Key database."but its a leap for me to read that and conclude "real user interface for making change" -- all I can read into is that if a such a user interface does exist it can't have authentication in the way.

Thank you Matthew in advance for any insight on the prospects of the Win 8 certified mandated setup mode being meaningful and useful to end users for key installation vs being a mirage.

There's no reason for setup mode to provide a UI. We'll be writing a tool that'll let you do the key enrolment once your machine is in setup mode. It'll also support switching you back to user mode if that's what you want.

Indeed, it would only make sense for firmware to provide a key change GUI if firmware was the only thing executable in setup mode, e.g. no code of your own allowed to run and perform the key setup.

Its good to hear we'll have the ability to run our own code in setup mode and to make real system changes that way -- not having to rely on upstream hardware vendors any more than necessary is a very good.

I know this isn't directly a MS Win 8 or UEFI matter, but I'm still feeling sad that many hardware vendors will disallow user-provided firmware updates (e.g. coreboot) in setup mode -- at least the reality of control over secure boot makes this a wish-had item over a must-have.

I appreciate why it is a good feature for a system owner who worries about other physically present people tampering with the system -- operating a chip programmer can be a more daunting matter, if I understand correctly this is especially hard when a surface mounted flash chip is involved without special programming pins available on the main board.

Would it not make sense for there to be open, neutral code signing bodies? Maybe two or three of the CAs would like to do it.

Being cynical, Microsoft has no incentive to do that, and the hardware vendors have little incentive to do anything beyond what Microsoft wants. Possibly the EU will in due course insist on something happening to avoid this constituting an anti-competitive practice?

Well, on the less evil side, one thing Canonical has over Microsoft in this case is that one can be pretty sure that Canonical is never going to change the x86/x64 requirements to be like Microsoft's WRT ARM hardware.

I certainly have a dreadful feeling that at some point in time Microsoft will attempt to require the evil restrictions they impose on ARM for future x86/x64 Windows certification (no disabling secure boot, no changing keys).

The more OEMs who include Canonical's (and other free OS people's) key, the better it will be for the lot of us in the future.

How does including Canonical's key help? The only people who can use that are Canonical. Having one key per OS just results in a split between the OS vendors who are big enough to get hardware vendors to include their key and the ones who aren't.

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.