Skip to comments.Red Hat & Ubuntu's UEFI Solutions Not Good For FOSS
Posted on 07/07/2012 3:49:02 PM PDT by ShadowAce
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 isnt 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. Its 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 Microsofts 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 Hats 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 dont think Microsoft has any business being involved in any way when a privately owned personal computer boots to Linux or BSD. It also doesnt seem right that Red Hat should have to throw money Redmonds way, even if its 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 dont have the resources. Others are anti-Microsoft to their core, which is their right, and will absolutely refuse to have Redmonds fingerprints on their product.
Ubuntus 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, theyll use Intels efilinus, which is covered under a more permissive license. Ubuntus Steve Langasek, explains their plans for Secure Boot this way:
Booting our CDs will rely on a loader image signed by Microsofts
WinQual key, for much the same reasons as Fedora: its 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 dont have to go through the WinQual signing process every time we want to make a minor change there). We hope that well 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 dont regress behavior for those with UEFI systems that do not implement Secure Boot or that have it disabled.
Everything thats wrong with Red Hats proposed implementation also applies to Ubuntus 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 users 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 Apples 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. Its 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. Its 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 Redmonds policy as a new standard. Tuesday, iTWires 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 Microsofts 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.
This ruined my day. My web server is on Fedora.
Hmmm...I wonder what actually goes on in that “secure loader”. On a virtualized machine...just about anything! Exactly who is is secure for?
Tell me about it. Fedora is what I run as well on my personal, general-purpose laptop.
Glad I moved to Saybayon...
Autocorrect be damned.
I think this laptop is running SUSE 11.1. It works. There are new versions. I see no need to upgrade.
Debian user here.
I hate to see this affliction strike ARM.
I program for ARM (gcc toolchain).
Arm is really moving into nearly everything.
My new toy, the Raspberry Pi has an ARM11 SOC
with a great GPU along side. Mine is playing a
blu ray of the old “Airport 1970” right now. I
sure miss Dean Martin...he’s great in this old film.
ARM is worse. Microsoft allows for the disabling of Secure Boot on x86 Windows 8 machines, but it will be required for ARM Windows 8 machines.
Not you, that's for sure. The entire "trusted computing" idea is based on mistrust established companies and organizations have for their "customers'.
I can't believe MS is able to specify that ARM devices must require that the 'secure loader' facilities be hardcoded and not bypassable by the owner of the device.
Another clue for folks that microsoft really is evil.