July 26, 2012, 10:37 AM — The Fedora Engineering Steering Committee has voted 7-0 to move forward with the Fedora Project's UEFI Secure Boot plan, thus formally activating the plan for the upcoming release of Fedora 18.
But with Fedora's Secure Boot solution moving forward, and Canonical addressing it with a plan of their own, where are the other Linux distros' ideas?
According to Linux Foundation Technical Advisory Board member James Bottomley, it may be that distros have had problems formulating a plan to deal with UEFI because they don't have access to UEFI machines.
"The Linux Foundation Technical Advisory Board have been looking into this because it turns out to be rather difficult to lay your hands on real UEFI Secure Boot enabled hardware," Bottomley wrote on the [linux-kernel] mailing list).
To alleviate this problem, Bottomley used a new Secure Boot tool within Intel's Tianocore UEFI implementation project to create a Tianocore boot system. The test platform was packaged in the openSUSE Build System and can be installed on nearly every Linux distro.
While "very alpha," Bottomley has has some success in using this to test run some Linux boots.
"The current state is that I've managed to lock down the secure boot virtual platform with my own PK and KEK and verified that I can generate signed efi binaries that will run on it (and that it will refuse to run unsigned efi binaries). Finally I've demonstrated that I can sign elilo.efi (this has to be built specially because of the bug in gnu-efi) and have it boot an unsigned linux kernel when the platform is in secure mode (I've booted up to an initrd root prompt)," Bottomley explained.
The new virtual platform has already been used to test various boot scenarios, including an openSUSE 12.1 experiment.
With testing tools in hand, we may start seeing new approaches to confronting the UEFI Secure Boot anvil hanging over Linux on the desktop.
Under the Windows 8 logo certification plan, all Windows 8 machines must have the Unified Extensible Firmware Interface (UEFI) instead of the BIOS firmware layer that most computers have been using for a while.
EFI, and the later UEFI specification, is not the problem for Linux--any distro running Linux 2.6 and after can handle UEFI. 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).
This means that any user who wants 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.
The plan that the Committee (otherwise known as FESCo) voted on this week was originally proposed in early June by Red Hat developer Matthew Garrett, which created a big stir, to say the least.
Instead of creating a Fedora-specific key that could unlock the UEFI secure boot feature (but only for Fedora), Garrett and his team proposed a two-stage bootloader approach that would necessitate using a Microsoft-signed certificate.
Using this Microsoft-signed certificate (acquired by paying a one-time $99 certification fee to Verisign), the first-stage bootloader's only task would be to 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 two-stage 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 procedure, too.
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 in his proposal.
The FESCo vote should come as no surprise, since Red Hat had blessed the idea soon after Garrett's proposal was made. 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," Tim Burke, VP Linux Engineering at Red Hat wrote at the time. "For users performing local customization, they will have the ability to self-register their own trusted keys on their own systems at no cost."
So far, the community hasn't erupted in outright revolt, but resentment exists over a solution that depends on Microsoft for any reason.
It's not like Microsoft didn't ask for this grief. Any overtures of peace the company might make to the Linux community are overshadowed by some dumb move or statement on their part, like their continued insistence to profit from insinuations that they control patents that Linux willfully violate.
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.