Linux Foundation recommends fixes for UEFI roadblock

Among ideas: a new vendor-neutral certificate authority for Linux ecosystem

The Linux Foundation has made its own response to the potential problem of UEFI secure boot being required for any device authorized to run Windows 8 with a technical whitepaper that describes how the problem can be avoided.

[ Goodbye BIOS, hello UEFI ]

Update: The Linux Foundation is not the only organization putting their two cents in. Interestingly, Red Hat and Canonical also released a joint whitepaper of their own at the same time Friday morning. The Red Hat/Canonical whitepaper makes similar and more specific recommendations, and is authored by James Bottomley, Matthew Garrett, and Canonical's Jeremy Kerr.

The whitepaper itself is not a hard-and-fast solution: it contains recommendations for hardware manufacturers and users. And at least one of these recommendations may call for the creation of something the Linux world has never had: a vendor-neutral certificate authority.

Before getting into the specifics of the Linux Foundation's recommendations, here's a quick review of what's going on:

In September one of the authors of the Red Hat/Canonical whitepaper, Red Hat developer Garrett, raised the concern that according to the new Windows 8 logo rules from Microsoft, all Windows 8 machines will need to be have the Unified Extensible Firmware Interface (UEFI) instead of the venerable BIOS firmware layer. Further, the system must support secure booting, which means that "all firmware and software in the boot process must be signed by a trusted Certificate Authority (CA)," according to slides from a presentation on the UEFI boot process made by Arie van der Hoeven, Microsoft Principal Lead Program Manager this fall.

After some community attention on Garrett's initial and subsequent blog posts on the issue, the open source and free software communities erupted into a fury: if OEM vendors implemented these features without some sort of loophole that enabled other operating systems to be loaded onto these machines, then native Linux operations on Windows 8 logoed machines would be impossible.

Many, including myself, speculated that while secure boot is a very good feature for any machine (especially one running virus-prone Windows) to have, Microsoft surely wasn't going to shed a tear if this secondary result of UEFI secure boot happened.

Garrett has continued to examine the topic of UEFI secure boot, in particular addressing what he believes is the real problem here: while Linux is more than capable of handling secure keys, how will Linux vendors and end users be able to acquire those keys and manage them? His concerns are echoed by the Free Software Foundation, which launched an online petition drive this month to demand that OEMs implement UEFI secure booting in such a way that will enable other operating systems to run on these machines.

Today's recommendation from the Linux Foundation is a detailed outline of just how OEMs can implement UEFI secure booting in such a way that will enable Windows 8 and Linux to enjoy the benefits of secure booting without excluding Linux and other operating systems (what the whitepaper terms "Open Platforms").

The Linux Foundation paper, also authored by Bottomley, as well as Jonathan Corbet, makes five specific recommendations:

  • "All platforms that enable UEFI secure boot should ship in setup mode where the owner has control over which platform key (PK) is installed. It should also be possible for the owner to return a system to setup mode in the future if needed.
  • "The initial bootstrap of an operating system should detect a platform in the setup mode, install its own key-exchange key (KEK), and install a platform key to enable secure boot.
  • "A firmware-based mechanism should be established to allow a platform owner to add new key-exchange keys to a system running in secure mode so that dual-boot systems can be set up.
  • "A firmware-based mechanism for easy booting of removable media.
  • "At some future time, an operating-system- and vendor-neutral certificate authority should be established to issue KEKs for third-party hardware and software vendors."

The trick, as Garrett and others have pointed out all along, is how Linux can play ball as a trusted operating system. To do this, Bottomley and Corbet write, would be to use the X509 trust model that would "[allow] signatures and signing keys to be traced back to a single root of trust. This would allow for one (or more) Certificate Authority (CA) keys to be placed in the UEFI signature database and would then allow the designated Certificate Authorities to issue both KEKs (and even signing keys that allow the production of KEKs) to third parties that would still validate back to the original CA root of trust.

"We therefore propose that all the interested parties establish a Certificate Authority whose key should be placed in the UEFI firmware table by default; this authority would become responsible for handing out signed KEKs to UEFI device vendors (for their UEFI drivers), UEFI OEM platform vendors (for their firmware images) and OS vendors (for securely booting their OSs). The operation of such a CA would have to be platform- and OS-neutral and would have to adhere to the usual standards of trust and security (presumably by having a controlling board made up of representatives from the various parties), but it would solve a greater part of the driver and OS verification problem because anything signed with an un-revoked KEK traceable back to the CA root key would be automatically trusted by the UEFI firmware for secure boot."

By setting up a vendor-neutral CA, Linux and other participating vendors would essentially bypass Garrett's concerns about the lack of a central CA, since they would have that centralized level of trust.

This recommendation is, very likely, going to be the most problematic of the bunch: these keys would have to be managed by an authority that would maintain absolute security control over the private half of the keys, be absolutely vendor neutral, and not exclude those distributions of Linux that are managed by hobbyists and volunteers. As Garrett writes in his October 19 blog:

"Remember, if any malware is signed with any of these keys, it'll boot on any machine carrying this key. It's a lot of trust. It's not obvious that there's an organisation with sufficient trust at the moment."

There is, potentially, another problem in the Linux Foundation's proposed solution. When the paper turned it attention to the issue of booting from external removable media, which nearly every Linux distribution that's being installed or run as a LiveCD has to do, it recommended using the X509 trust model to solve the issue. But what if the removable media isn't signed with a key that goes back to this hypothetical CA? Here's what Bottomley and Corbet recommend:

"In the absence of the establishment of a trust model, we therefore recommend that non-verifying external media be booted with a simple firmware based present user permission check when the system is in user mode with secure boot enabled."

This is something that Garrett had already addressed in his October 19 blog entry. And, if Garrett is correct, this solution won't work. Here's what Garrett posits will happen when user permission is queried:

"This is a little awkward for a couple of reasons. First, it means that any updates to the bootloader would require the user to manually accept the binary again. Second, as we've seen with https, there's the risk of [users] just blindly accepting things. If it's acceptable to do this off internal media then malware could just rely on some number of users saying 'yes'. And thirdly, we've been told that Microsoft's Windows logo requirements forbid this option.

"The first is problematic but manageable with appropriate documentation. The second is a real risk that makes this approach far less compelling. And the third is probably a showstopper."

In the end, if Garrett's position is correct, it's not a showstopper for running Linux from removable media; it just means that media had better have a signed key somewhere.

In all, this is going to be a much more complicated solution that was originally thought. Since OEMs may not be able or willing to completely switch off secure boot mode, the Linux Foundation's suggested "setup mode" might be a good compromise. But it still leaves the question of what organization will be able to handle the duties of certificate authority for serving the Open Platform community.

And it doesn't address the unspoken question of whether the OEMs will go along with these recommendations.

The journey to solving the problem of UEFI secure boot made a good step today, but there's still a long way to go.

Read more of Brian Proffitt's Open for Discussion blog and follow the latest IT news at ITworld. Drop Brian a line or follow Brian on Twitter at @TheTechScribe. For the latest IT news, analysis and how-tos, follow ITworld on Twitter and Facebook.

ITWorld DealPost: The best in tech deals and discounts.
Shop Tech Products at Amazon