Free Software Foundation vs Microsoft Windows 8 “Secure Boot”
So far, the “Secure Boot” feature that Microsoft requires for Windows 8-certified hardware has caused a lot more anxiety in the Linux community than actual harm. Most Linux distributions have viable plans for working around the potential problems that Secure Boot poses. Nonetheless, the Free Software Foundation has embarked on a campaign to fight the feature tooth-and-nail. And it wants your help.
Promoted by Microsoft as an extra layer of security, Secure Boot is a feature embedded into device firmware that prevents unauthorized operating systems from booting. That means PCs designed for Windows 8 could refuse to run Linux out-of-the-box.
But while that may sound worrying for open-source fans, the actual threat is pretty minimal. Most Linux distributions have strategies in place for working around the Secure Boot limitations by signing the requisite open-source bootloader software (in most cases, Grub 2) with keys that the firmware will recognize, allowing Linux kernels to boot.
Without a doubt, Secure Boot doesn’t make the lives of Linux users any easier, and it has caused development delays for distributions like Fedora (though those stemmed from squabbling between developers over which method to adopt in working around Secure Boot, rather than from the technical challenges it poses), but it won’t eradicate open-source operating systems from the world in the way some doom-and-gloomers predicted when Microsoft announced the feature.
Still, the Free Software Foundation, one of the open-source channel’s most influential organizations in moral (if not financial) terms, is aggressively combating Secure Boot with a multi-channel campaign. The group plans to educate the public on avoiding Secure Boot-enabled hardware, pressure device manufacturers to avoid measures that will prevent consumers from installing the software they wish and combat Microsoft’s proposal for implementing a similar feature on ARM-powered smartphones and tablets.
To advance its efforts, the FSF has created a petition, signed so far by more than 40,000 individuals and 50 organizations. The signatories pledge not to purchase hardware that fails to “provide a sure-fire way for them to install and run a free software operating system of their choice.” The FSF also invites users to donate $50, although it’s not clear whether that money will be used to combat Secure Boot specifically, or support the FSF’s operations more generally.
From my perspective, the FSF’s campaign against Secure Boot is noble enough. As a committed open-source user and advocate, however, I also worry that the group has not defined exactly what it hopes to achieve. Its stated aims are not to do away with Secure Boot entirely (a goal which even the ideological stalwarts at the FSF, apparently, recognize as impossible to achieve), but merely to ensure that the feature is implemented in a way that ensures users the freedom to install the operating system of their choice. So far, that freedom seems to remain intact, so it’s not entirely clear what changes the FSF would like to see.
That said, public resources that would help consumers avoid Secure Boot-enabled hardware would certainly not hurt. Nor would efforts to keep users aware of this issue in order to help prevent monopolistic abuse from occurring in the future. Kudos to the FSF for this work.
“Freedom is intact”… accept that so far every pre-loaded system I have seen with Windows 8 on it has a completely hidden UEFI trigger which presents a local user a window of less than 3 seconds on boot to press. As in, the old “configure your BIOS by pressing F11” thing is now a random mystery key you have to hunt for because the display is disabled by default (with no way to turn it on) on Lenovo, HP and Toshiba systems I’ve seen. So the average user cannot easily disable “secure boot”, but those with criminal intent and a motivation to learn what the key is will anyway.
How is this freedom? One of the chief advantages of many open source distro is their extreme ease of installation and the ability to run from external media, which is completely disabled in many cases and not always configurable from within every secure boot enabled UEFI system.
You are vastly minimalizing the problem in this article. I suggest you go snoop around some forums with first-hand accounts of actual users trying to install their own OSes on new hardware before passing this off as an overreaction by the FSF.
Ah… also, some systems require the special key to be pressed every time the system is booted or re-botted, always. This means those systems are completely useless for wake-on-LAN, timed boot, remote recovery, remote administration requiring reboot, scheduled reboots or any other administration task that requires cycling the power — not to mention the awesome power of remote network installation of 100’s of client systems at once via kickstart is completely gone.
What that really means is the list of hardware I can buy to service business clients has shrunk by a huge amount. Its now a case of build-it-in-house or go out of business because no small computing service provider companies have the clout or volume to get workable prebuilt systems from the big vendors.
I will solve the problem by buying a ZaReason or System 76 computer. I see Dell and HP are offering Ubuntu also, and I am guessing those will not have secure boot. If Microsoft wants to play that game, they will lose me. I could also boot XP in Virtual box if I need too. I have an old XP disc.
“Nonetheless, the Free Software Foundation has embarked on a campaign to fight the feature tooth-and-nail”
Actually, it hasn’t. It is fighting what it terms ‘Restricted Boot’, which is firmwares which implement Secure Boot in such a way that you cannot turn it off or configure the list of trusted keys.
Most implementations of SB firmwares *do* allow you to disable it and configure the list of trusted keys, therefore they do not meet the FSF’s definition of ‘Restricted Boot’ and the FSF is not ‘fighting’ them ‘tooth-and-nail’.
See https://www.fsf.org/campaigns/campaigns/secure-boot-vs-restricted-boot .
“As in, the old “configure your BIOS by pressing F11″ thing is now a random mystery key you have to hunt for because the display is disabled by default (with no way to turn it on) on Lenovo, HP and Toshiba systems I’ve seen”
That’s hardly new to UEFI. There has never been a universal key to enter the system firmware on PCs. F11 by no means works on all systems; hell, it doesn’t work on any system I have here (I have systems that use F2 and systems that use Del, I think).
“Without a doubt, Secure Boot doesn’t make the lives of Linux users any easier, and it has caused development delays for distributions like Fedora (though those stemmed from squabbling between developers over which method to adopt in working around Secure Boot, rather than from the technical challenges it poses”
This is also inaccurate. SB implementation has not been a significant roadblock for Fedora 18’s release (the new installer UI is the main issue blocking F18’s release), and there has been very little such ‘squabbling’. There is exactly one SB implementation that anyone is actually using: Matthew Garrett’s ‘shim’ bootloader. Ubuntu 12.10 uses this, Fedora 18 will use it, OpenSUSE and Sabayon will also use it; I don’t know of any distro planning to use anything else. The Linux Foundation came up with a similar design but it offers no advantages over shim and is at an earlier stage of development, so there doesn’t seem to be any particular point to it.
Ubuntu 12.10 shipped back in October with SB support, using a build of shim signed by Microsoft. Fedora has a build of shim signed by Microsoft in hand for Fedora 18; F18 test builds since TC3 work fine on SB systems (this has been tested). Current Sabayon test builds also work fine using the shim self-enrolment mechanism. This is all out in the wild, tested and working, there are no roadblocks.
I haven’t yet tried to install Linux on a system with Secure Boot, but someone close to me did (Ubuntu 12.10), and the exprience wasn’t easy. There was quite a lot of head scratching, hunting for information and trials and errors. This person has years of Linux experience, and is used to do OS installations and to work with BIOS settings. If the process doesn’t get easier, regular computer users intending to give Linux a try will in most cases turn away before they even see Linux.
ademeion: there is a lot of confusion between UEFI and Secure Boot. They aren’t the same thing. If you’ve never done a native UEFI install before, it’s pretty different from BIOS.
A UEFI install of Ubuntu 12.10 with Secure Boot enabled, compared to a UEFI install of Ubuntu 12.10 with SB disabled, will look about 99.9% identical. It’s just not a very visible feature at all. Ditto F18.
I suspect most of your friend’s confusion was to do with UEFI, not SB.
Useful. I agree.