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 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
Talking about what Microsoft “should” do vis-a-vis secure boot is typically irrelevant FSF moral ranting. They see this as a moral and ethical issue. Fine. But why should a hardware vendor who is commited to making a profit convert to FSF’ism and start selling hardware that won’t run Windows?
Where was the FSF before Microsoft’s implementation of Secure Boot became a fait accompli? Why weren’t they influencing the outcome of discussions on UEFI/Securte Boot? Now, they’re sitting back taking holier-than-thou potshots at people who actually distribute products that normal people use and expecting them to hobble themselves just to please the FSF.
If the FSF wants to lead the free software world, then it needs to be there when it counts, not show up after the fact and demand sacrificial victims to its brand of purity.
Yet another article stating how Linux companies who are doing well should sacrifice themselves.
While I agree that Microsoft is using monopolistic means to harm non-Microsoft software companies, I don’t agree that companies who have a large stake in this should only take one form of action.
Red Hat and Ubuntu are still free to pursue charges that Microsoft is behaving illegally. And they are now able to weather the storm this has caused.
It does not take a genius to workout that governments world wide are not going to be dictated to by Microsoft telling them they have to use windows 8. Pay MS billions of dollars annually for the end users license fees and support. for the privilege.
I do not want to dive into doucheness discussion who is the doucheiest of them all. (personally I do not like Dell not providing the option to ship the drive without OS bit either shmackintoze or shwindoze — as a result i end up paying extra dollaz for bits free harddrive) anyhow…
There has to be trusted third party (TTP) when it comes to key signing and distribution. This way either shaft or buntu or red hate chain off from TTP hierarchy. Other ways they will otherwise tear up and try dying to get the bananas. the sad thing is that most do not understand the problem well.
one thing for sure… there will be other ways as well as other schemes to secure boot. then, you all saw that comment about hashing rather than signing then encrypting and current hardware 1024 bit limit
@joncr: FSF protested loudly long before the MS “Secure Boot” implementation became “fait accompli”, but you weren’t there to support them, and they failed. Where you were?
@yort: It is too attractive to some Big Corp mentality to see the other Linux distros as the competitor, and MS as the friend. Or maybe there is some new warmth between MS and Red Had / Ubuntu we don’t know of…
Can somebody please describe the risk that “secure boot” is supposed to mitigate? Aliens changing my operating system during the night?
Most end users and businesses never change their operating system. This whole story seems to be designed by Microsoft to cause disruption to competitors.
What is the risk that “secure boot” is supposed to mitigate?
1: install (or keep the presently installed) windows.
2: run a bios flasher and overwrite the devil-code with a patched bios.
3: erase the rubish from the harddrive.
4: install your o.s. of choice.
A risk analysis here:
“I think this just another piece of security theater that will inconvenience many and benefit no one.
Ditch Red Hat and Ubuntu and install Debian….Tell Microsft to fu..k off..
Since when has Micro$oft been dominating the ARM processor market? Have they not they tryed to enter this market many times. Have they ever had more than a single digit market share in the ARM market? They are trying again with the Surface tablet.
The other thing about the ARM market is that devices thend to be purpose built for a specific use like cell phones and tablets. Have not seen many articles on replacing Android with a linux distro yet.
[…] means does not work with Linux — a claim that the FSF has been challenging and others played along with. As Christine Hall put it: “The FOSS community is understandably upset with both Red Hat and […]
Comments are closed.