Linux UEFI compromise reasonable, still sucks

Fedora proposal is the lesser of all evils

Life is full of trade-offs, and many times they are not palatable for every side. Such was the trade-off proposed by Fedora developers this week to solve the upcoming obstacle of UEFI secure booting on Windows 8-certified machines.

All Windows 8 machines will need to be have the Unified Extensible Firmware Interface (UEFI) instead of the venerable BIOS firmware layer. BIOS has been pretty much the sole firmware interface for PCs for a long time.

The EFI system has slowly been making headway in recent years, and right now EFI firmware is compatible with Windows supporting the GUID Partition Table (GPT), OS X/Intel, and Linux 2.6 and beyond machines. EFI is seen as a better hardware/software interface than BIOS, since it is platform-agnostic, runs in 32- or 64-bit mode, and GPT machines can handle boot partitions of up to 9.4 zettabytes. (That's 9.5 billion terabytes to you and me.)

EFI, and the later UEFI specification, is not the problem for Linux. The problem is Microsoft's other requirement for any Windows 8-certified client: the system must support secure booting. This hardened boot means that "all firmware and software in the boot process must be signed by a trusted Certificate Authority (CA)," according to slides from a recent presentation on the UEFI boot process made by Arie van der Hoeven, Microsoft Principal Lead Program Manager.

In such a situation, any user who wanted to dual-boot on a Windows 8-certified machine would be unable to accomplish the task, unless they had a signed key the UEFI secure boot system recognized.

Red Hat developer Matthew Garrett has been trying to find a solution for this major obstacle since he brought it to public attention last Fall. Last week, his proposal sent shockwaves through the community. Rather than create a Fedora-specific key that could unlock the UEFI secure boot feature (but only for Fedora), Garrett and his team are proposing a more open two-stage bootloader approach.

After paying a one-time $99 certification fee to Verisign for a Microsoft-signed certificate, the first-stage bootloader will have one job: boot to a second bootloader that's signed with a Fedora key and have the second bootloader (Grub 2.0) roll into Fedora or whatever the user chooses.

This approach has the advantage of not letting Fedora getting a leg up over any other distro, since other distros can just pay that $99 fee and make their own two-stage bootloader approach.

There are other advantages: "The first stage bootloader should change very rarely, and we don't envisage updating it more than once per release cycle. It shouldn't be much of a burden on release management," Garrett wrote.

Apparently his bosses like the proposal, too. Yesterday, Tim Burke, VP Linux Engineering at Red Hat posted a blog of his own outlining the need to implement a proposal like Garrett's.

"A healthy dynamic of the Linux open source development model is the ability to roll-your-own. For example, users take Fedora and rebuild custom variants to meet personal interest or experiment in new innovations. Such creative individuals can also participate by simply enrolling in the $99 one time fee to license UEFI. For users performing local customization, they will have the ability to self-register their own trusted keys on their own systems at no cost."

Another reason Fedora likes this approach is the ease-of-use it brings to the average desktop user. Yes, you can turn secure boot off in UEFI, but the concern is that the "average" user won't be able to easily manage it or even want to turn off a feature that's clearly labeled "secure."

For a compromise, this is likely the best solution that the Linux community could have found. There is no word from the Ubuntu and openSUSE communities on what they will be doing about UEFI yet, but already one openSUSE engineer is calling for an evaluation of Fedora's proposal. Which, really, they should.

But it still sucks.

It sucks because once again, through sheer market strength, Microsoft has been able to implement a unilateral position with hardware vendors that puts other operating systems at a big disadvantage.

It sucks because there's no evidence that this secure boot requirement will even work. The Flame malware incident, which used a forged Microsoft certificate to distribute malware, demonstrated quite clearly that certificates are not the be-all-end-all for security. (And no one, by the way, will be able to convince me that Flame wasn't a trial run for just the Windows 8 secure boot requirement.)

It sucks because if there was ever palatable proof that the Linux desktop has gotten nowhere--nowhere--in the 10 years or so since the first "Year of the Linux Desktop," this is certainly it. Clamor all you want to hardware vendors to stand up to Microsoft's demands and you will hear only echoes. Linux on the desktop simply does not have the market share to obtain reasonable business decisions from desktop hardware vendors.

The above is just me grouching off, mostly. No compromise can please everyone, and clearly I fall into the non-pleased category.

There is one desktop Linux vendor that could go its own way to get their own signed distribution: Google. ChromeOS, thanks to Google's wallet, already has an OEM deal with Samsung, and could conceivably just have machines produced that have UEFI with ChromeOS-only secure boot, no secure boot, or heck, even no UEFI.

A successful ChromeOS won't really help the at-large Linux desktop ecosystem, since there aren't a lot of native apps on ChromeOS (nor will there be, if this week's acquisition of QuickOffice by Google is any indication). But it could be the only variation in a proposal that's the lesser of all evils.

Read more of Brian Proffitt's Zettatag and Open for Discussion blogs 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.

Insider: How the basic tech behind the Internet works
Join the discussion
Be the first to comment on this article. Our Commenting Policies