Red Hat & Ubuntu’s UEFI Solutions Not Good For FOSS

The FOSS community is understandably upset with both Red Hat and Ubuntu for their planned ways of implementing UEFI Secure Boot. Indeed, both companies plans are unacceptable for a variety of reasons. Free software isn’t free if it requires permission from an outside source before it can be loaded onto a new or used computer. This is true even if the permission comes from a well-meaning bureaucratic regulatory agency. It’s doubly true if that permission must come from a self-serving monopoly with an anti-FOSS history, like Microsoft.

In early June, Red Hat came under fire from the FOSS press for their way of getting around Secure Boot. Their solution, which will also be used by Fedora, involves joining Microsoft’s developer program in order to obtain a key to be used to load a “shim” bootloader which will then load GRUB. In a post on Red Hat’s web site explaining the move, Tim Burke, Vice President of Linux Engineering, seemed to be dismissing these critics in a terse two sentence paragraph near the end of the post:

“Some conspiracy theorists bristle at the thought of Red Hat and other Linux distributions using a Microsoft initiated key registration scheme. Suffice it to say that Red Hat would not have endorsed this model if we were not comfortable that it is a good-faith initiative.”

Indeed, some critics don’t think Microsoft has any business being involved in any way when a privately owned personal computer boots to Linux or BSD. It also doesn’t seem right that Red Hat should have to throw money Redmond’s way, even if it’s only $99.00. A fraction of a penny per Fedora download still smacks of a Microsoft tax to some.

There are other problems with this solution, not the least of which is its lack of universality. If this plan became the standard, every distro and its brother would have to sign up with Microsoft and throw $99.00 at them to get their own key. Some distros don’t have the resources. Others are anti-Microsoft to their core, which is their right, and will absolutely refuse to have Redmond’s fingerprints on their product.

Ubuntu’s solution is even less acceptable. They plan to have their own key embedded in the firmware and will also use a key obtained from from Microsoft. Because of fears the GPL will force them to make their key public, Ubuntu will also do away with the use of GPL licensed GRUB as a bootloader on Secure Boot enabled devices. Instead, they’ll use Intel’s efilinus, which is covered under a more permissive license. Ubuntu’s Steve Langasek, explains their plans for Secure Boot this way:

“Booting our CDs will rely on a loader image signed by Microsoft’s
WinQual key, for much the same reasons as Fedora: it’s a key that, realistically, more or less every off-the-shelf system is going to have, as it also signs things like option ROMs, and the UEFI specification only allows an image to be signed by a single key. This will then chain to efilinux signed by our own key (so we don’t have to go through the WinQual signing process every time we want to make a minor change there). 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 behavior for those with UEFI systems that do not implement Secure Boot or that have it disabled.”

Everything that’s wrong with Red Hat’s proposed implementation also applies to Ubuntu’s plan. In addition, by using their own firmware embedded key, they are lending legitimacy to a process that is at least a bad idea and at worst an attempt by Microsoft to hold on to a monopoly they are in the process of losing. Of particular concern to the Free Software Foundation (FSF) is the dropping of GRUB for efilinus:

“Our main concern with the Ubuntu plan is that because they are afraid of falling out of compliance with GPLv3, they plan to drop GRUB 2 on Secure Boot systems, in favor of another bootloader with a different license that lacks GPLv3’s protections for user freedom. Their stated concern is that someone might ship an Ubuntu Certified machine with Restricted Boot (where the user cannot disable it). In order to comply with GPLv3, Ubuntu thinks it would then have to divulge its private key so that users could sign and install modified software on the restricted system.

“This fear is unfounded and based on a misunderstanding of GPLv3. We have not been able to come up with any scenario where Ubuntu would be forced to divulge a private signing key because a third-party computer manufacturer or distributor shipped Ubuntu on a Restricted Boot machine. In such situations, the computer distributor — not Canonical or Ubuntu — would be the one responsible for providing the information necessary for users to run modified versions of the software.

“Furthermore, addressing the threat of Restricted Boot by weakening the license of the bootloader is backwards. With a weaker license, companies will now have a form of advance permission to obstruct the user’s ability to run modified software. Rather than work to make sure this situation does not happen — for example by enforcing the proper Secure Boot implementation they say they “strongly support in [their] own firmware guidelines” — Ubuntu has chosen a path which explicitly allows Restricted Boot.”

In this case, the FSF is spot on the mark. If Microsoft wants to follow Apple’s lead and build their own computers designed to run only Windows, they are free to do so. But as long as they are acting merely as a software vendor, they should not be allowed to change established standards in a way that requires developers of other operating systems to go through Redmond in order for their software to be installable.

Likewise, device owners should be able to load whatever they like on their hard drives, without having to jump through hoops to do so. It’s not a level playing field when Fedora or Ubuntu, but not Debian or Slackware, can be installed on a Samsung tablet that was originally equipped with Windows, because of signing key issues.

The Secure Boot problem will mostly effect ARM devices, such as phones, tablets and netbooks. Early pressure from the Linux community has caused most x86 OEMs to promise to include a way to disable Secure Boot on traditional Wintel machines. However, Microsoft has mandated that no such opt-out will be allowed with ARM.

This would seem to make traditional computers safe, but probably not for long. It’s only a matter of time before the use of power sipping processors like ARM expand beyond the world of hand held devices and start being utilized in desktops and laptops as well.

For Linux distributions to cooperate with Microsoft at this point only sets a precedent that will help solidify Redmond’s policy as a new standard. Tuesday, iTWire’s Sam Varghese pointed out how counter intuitive it is for Red Hat or Ubuntu to cooperate with Microsoft in this way:

“In both methods, advocated by Red Hat and Canonical, one is dependent on Microsoft. A convicted monopolist, the company is famous for making little tweaks to things so that competitors’ products become unusable. But both Red Hat and Canonical seem comfortable with snuggling under the same blanket as Microsoft.”

Instead of cooperating with Microsoft’s bid to put a lock on the operating system market, we should be fighting them. For starters, it would appear there are some antitrust issues that could possibly be pursued. Maybe Google could put some pressure on companies making Android ARM devices to just say no to Secure Boot without an easy-to-use “off” button.

There are plenty of geniuses at Red Hat and Ubuntu. They can think of a better way to deal with this issue.

Christine Hall

Christine Hall has been a journalist since 1971. In 2001, she began writing a weekly consumer computer column and started covering Linux and FOSS in 2002 after making the switch to GNU/Linux. Follow her on Twitter: @BrideOfLinux

FOSSForce.com