Canonical details plans to deal with UEFI Secure Boot
Their own Ubuntu key, no default GRUB 2 on Secure Boot systems
The problem of dealing with UEFI's Secure Boot in Windows 8-certified PCs is still being wrestled with by various Linux distros, and today the Ubuntu team has revealed more about their proposed solution. First up: dropping the GRUB 2 bootloader as a default tool on systems with Secure Boot enabled and generating an Ubuntu-specific signing key to use with UEFI.
That's the word from Steve Langasek, who--along with fellow Ubuntu developers Colin Watson and Jeremy Kerr--posted a detailed message to the [ubuntu-devel] mailing list earlier today.
That Ubuntu would be using its own signing key rather than pick one up from Microsoft via VeriSign is not exactly news: Mark Shuttleworth mentioned the approach in a message to the same mailing list on Wednesday.
"We've been working to provide an alternative to the Microsoft key, so that the entire free software ecosystem is not dependent on Microsoft's goodwill for access to modern PC hardware," Shuttleworth wrote in response to a question posed by my colleague Steven Vaughan-Nichols (who nicely wrote it up along with responses from the Fedora community).
Today's message from Langasek highlights how Canonical will be taking Ubuntu on a different course to solve the issue of Secure Boot.
In a nutshell, here's the issue: Microsoft is requiring OEMs making Windows 8-certified machines to use 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 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."
Meaning that, 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.
Fedora's proposed solution to this problem is to purchase a Microsoft-signed encryption key from VeriSign for a one-time $99 fee and use a two-stage bootloading process to (1) use the key to boot straight to a modified GRUB 2 bootloader that will (2) then boot to Fedora.
Canonical doesn't like that approach.
"So, the bad news first: at this point, we are not planning to use GRUB 2 by default on systems with secure boot enabled. As a search through its ChangeLog will show, we've put a considerable amount of upstream development effort into GRUB 2 and we hope to carry on doing so, so this wasn't an easy decision," Langasek wrote today.
Their reason? A legal concern--not technical--that a manufacturer mistake could end up requiring Canonical to have to reveal their private key.
"The reason we've arrived at a different plan is that Ubuntu has a rather extensive base of preinstalled systems. Microsoft's Windows 8 logo requirements do say that there must be a way for users to disable secure boot or to install their own keys, and we strongly support this in our own firmware guidelines; but in the event that a manufacturer makes a mistake and delivers a locked-down system with a GRUB 2 image signed by the Ubuntu key, we have not been able to find legal guidance that we wouldn't then be required by the terms of the GPLv3 to disclose our private key in order that users can install a modified boot loader. At that point our certificates would of course be revoked and everyone would end up worse off."
So how will this work, exactly? First, for users booting from CD, there will be a loader image signed by Microsoft's WinQual key, which will then chain to the UEFI bootloader efilinux. efilinux will be signed by Ubuntu's key, so the WinQual key won't have to be signed every time a change is made to efilinux.
GRUB 2 won't be going away completely.
"We hope that we'll also be able to make the first stage loader detect whether Secure Boot is enabled and otherwise chain to GRUB 2, to ensure that we don't regress behaviour for those with UEFI systems that do not implement Secure Boot or that have it disabled," Langasek added.
For machines with Ubuntu preinstalled, the process is similar, just more baked in.
"Machines that ship as 'Ubuntu certified' will be required to have an Ubuntu key configured in their UEFI signature databases. The intention here is to allow these systems to receive updates for the revoked signature database, in order to be protected against known-compromised UEFI binaries," Langasek wrote. "We are not planning to provide an alternative to Microsoft's signing infrastructure, only an additional key; so we have no current plans to implement a signing service using the Ubuntu key."
Nothing is set in stone yet, of course, but Canonical has made is abundantly clear that they want to have some measure of control in the Secure Boot process. And there are likely to be more proposals and plans to come.
"…W]e're committed to ensuring that Ubuntu will work smoothly with Secure Boot enabled hardware," wrote Canonical's VP, Professional & Engineering Services Jon Melamut on [the Canonical Blog tot/). "In addition to investigating Microsoft's recommendation to participate in its WinQual program, Canonical has generated an Ubuntu key, and we are in active discussions with partners to implement simple ways for enterprises and consumers to use this key. These conversations have not concluded, and as a result we cannot detail the plans of our OEM partners yet."
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.