![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Secure Boot and Restricted Boot.
I gave a presentation at Libreplanet this weekend on the topic of Secure Boot and Restricted Boot. There's a copy of the video here - it should be up on the conference site at some point. It turned out to be excellent timing, in that a group in Spain filed a complaint with the European Commission this morning arguing that Microsoft's imposition of Secure Boot on the x86 client PC market is anticompetitive. I suspect that this is unlikely to succeed (the Commission has already stated that the current implementation appears to conform to EU law), and I fear that it's going to make it harder to fight the real battle we face.
Secure Boot means different things to different people. I think the FSF's definition is a useful one - Secure Boot is any boot validation scheme in which ultimate control is in the hands of the owner of the device, while Restricted Boot is any boot validation scheme in which ultimate control is in the hands of a third party. What Microsoft require for x86 Windows 8 devices falls into the category of Secure Boot - assuming that OEMs conform to Microsoft's requirements, the user must be able to both disable Secure Boot entirely and also leave Secure Boot enabled, but with their own choice of trusted keys and binaries. If the FSF set up a signing service to sign operating systems that met all of their criteria for freeness, Microsoft's requirements would permit an end user to configure their system such that it refused to run non-free software. My system is configured to trust things shipped by Fedora or built locally by me, a decision that I can make because Microsoft require that OEMs support it. Any system that meets Microsoft's requirements is a system that respects the freedom of the computer owner to choose how restrictive their computer's boot policy is.
This isn't to say that it's ideal. The lack of any common UI or key format between hardware vendors makes it difficult for OS vendors to document the steps users must take to assert this freedom. The presence of Microsoft as the only widely trusted key authority leaves people justifiably concerned as to whether Microsoft will be equally aggressive in blacklisting its own products as it will be in blacklisting third party ones. Implementation flaws in a (very) small number of systems have resulted in correctly signed operating systems failing to boot, requiring users to update their firmware before being able to install anything but Windows.
But concentrating on these problems misses the wider point. The x86 market remains one where users are able to run whatever they want, but the x86 market is shrinking. Users are purchasing tablets and other ARM-based ultraportables. Some users are using phones as their primary computing device. In contrast to the x86 market, Microsoft's policies for the ARM market restrict user freedom. Windows Phone and Windows RT devices are required to boot only signed binaries, with no option for the end user to disable the signature validation or install their own keys. While the underlying technology is identical, this differing set of default policies means that Microsoft's ARM implementation is better described as Restricted Boot. The hardware vendors and Microsoft define which software will run on these systems. The owner gets no say.
And, unfortunately, Microsoft aren't alone. Apple, the single biggest vendor in this market, implement effectively identical restrictions. Some Android vendors provide unlockable bootloaders, but others (either through personal preference or at the behest of phone carriers) lock down their platforms. A naive user is likely to end up purchasing a device that will, in the absence of exploited security flaws, refuse to run if any system components are modified. Even in cases where the underlying components are built using free software, there's no guarantee that the user will have the ability to assert any of those freedoms.
Why does this matter? Some of these platforms (notably Windows RT and iOS, but also some Android-based devices) will even refuse to run unsigned applications. Users are unable to write their own software and distribute it to others without agreeing to often onerous restrictions. Users with the misfortune of living in the wrong country may be forbidden from even that opportunity. The vendor may choose to block applications that compete with their own, reducing innovation. The ability to explore and tinker with the components of the system is restricted, making it harder for users to learn how modern operating systems work. If I own a perfectly functional phone that no longer receives vendor updates, I don't even have the option of paying a third party to ensure that I can't be compromised by a malicious website and risk the loss of passwords or financial details. The user is directly harmed by these restrictions.
I won't argue that there are no benefits to curated software ecosystems. I won't even argue against devices shipping with a locked down policy by default. I will strongly argue that the owner of a device should not only have the freedom to choose whether they wish to remain within those locked-down boundaries, but should also have the freedom to impose their own boundaries. There should be no forced choice between freedom and security.
Those who argue against Secure Boot risk depriving us of the freedom to make a personal decision as to who we trust. Those who argue against Secure Boot while ignoring Restricted Boot risk depriving us of even more. The traditional PC market is decreasing in importance. Unless we do anything about it, free software will be limited to a niche group of enthusiasts who've carefully chosen from a small set of devices that respect user freedom. We should have been campaigning against Restricted Boot 10 years ago. Don't delay it even further by fighting against implementations that already respect user freedom.
Secure Boot means different things to different people. I think the FSF's definition is a useful one - Secure Boot is any boot validation scheme in which ultimate control is in the hands of the owner of the device, while Restricted Boot is any boot validation scheme in which ultimate control is in the hands of a third party. What Microsoft require for x86 Windows 8 devices falls into the category of Secure Boot - assuming that OEMs conform to Microsoft's requirements, the user must be able to both disable Secure Boot entirely and also leave Secure Boot enabled, but with their own choice of trusted keys and binaries. If the FSF set up a signing service to sign operating systems that met all of their criteria for freeness, Microsoft's requirements would permit an end user to configure their system such that it refused to run non-free software. My system is configured to trust things shipped by Fedora or built locally by me, a decision that I can make because Microsoft require that OEMs support it. Any system that meets Microsoft's requirements is a system that respects the freedom of the computer owner to choose how restrictive their computer's boot policy is.
This isn't to say that it's ideal. The lack of any common UI or key format between hardware vendors makes it difficult for OS vendors to document the steps users must take to assert this freedom. The presence of Microsoft as the only widely trusted key authority leaves people justifiably concerned as to whether Microsoft will be equally aggressive in blacklisting its own products as it will be in blacklisting third party ones. Implementation flaws in a (very) small number of systems have resulted in correctly signed operating systems failing to boot, requiring users to update their firmware before being able to install anything but Windows.
But concentrating on these problems misses the wider point. The x86 market remains one where users are able to run whatever they want, but the x86 market is shrinking. Users are purchasing tablets and other ARM-based ultraportables. Some users are using phones as their primary computing device. In contrast to the x86 market, Microsoft's policies for the ARM market restrict user freedom. Windows Phone and Windows RT devices are required to boot only signed binaries, with no option for the end user to disable the signature validation or install their own keys. While the underlying technology is identical, this differing set of default policies means that Microsoft's ARM implementation is better described as Restricted Boot. The hardware vendors and Microsoft define which software will run on these systems. The owner gets no say.
And, unfortunately, Microsoft aren't alone. Apple, the single biggest vendor in this market, implement effectively identical restrictions. Some Android vendors provide unlockable bootloaders, but others (either through personal preference or at the behest of phone carriers) lock down their platforms. A naive user is likely to end up purchasing a device that will, in the absence of exploited security flaws, refuse to run if any system components are modified. Even in cases where the underlying components are built using free software, there's no guarantee that the user will have the ability to assert any of those freedoms.
Why does this matter? Some of these platforms (notably Windows RT and iOS, but also some Android-based devices) will even refuse to run unsigned applications. Users are unable to write their own software and distribute it to others without agreeing to often onerous restrictions. Users with the misfortune of living in the wrong country may be forbidden from even that opportunity. The vendor may choose to block applications that compete with their own, reducing innovation. The ability to explore and tinker with the components of the system is restricted, making it harder for users to learn how modern operating systems work. If I own a perfectly functional phone that no longer receives vendor updates, I don't even have the option of paying a third party to ensure that I can't be compromised by a malicious website and risk the loss of passwords or financial details. The user is directly harmed by these restrictions.
I won't argue that there are no benefits to curated software ecosystems. I won't even argue against devices shipping with a locked down policy by default. I will strongly argue that the owner of a device should not only have the freedom to choose whether they wish to remain within those locked-down boundaries, but should also have the freedom to impose their own boundaries. There should be no forced choice between freedom and security.
Those who argue against Secure Boot risk depriving us of the freedom to make a personal decision as to who we trust. Those who argue against Secure Boot while ignoring Restricted Boot risk depriving us of even more. The traditional PC market is decreasing in importance. Unless we do anything about it, free software will be limited to a niche group of enthusiasts who've carefully chosen from a small set of devices that respect user freedom. We should have been campaigning against Restricted Boot 10 years ago. Don't delay it even further by fighting against implementations that already respect user freedom.
Re: SecureBoot setting, versus SecureBoot philosophy
(Anonymous) 2013-09-01 08:12 am (UTC)(link)In a larger sense, though, it seems flat wrong to say that the trouble was 'nothing' to do with SecureBoot, and furthermore that 'everybody' else in the world had 'no' difficulty whatsoever. Umm... perhaps we're not even talking about the same "discussion" here at all? I'm specifically referring to the amazon 41-strong review thread, and the sub-thread thereof which is the 37 replies to the review by Tony. (To be clear, this is the *only* discussion I've looked at, pertaining to this particular laptop -- I did not google the model and vendor to see what other folks had to say about the ability to install Linux and/or boot from USB. Just the amazon stuff, is all I ever looked at.)
http://www.amazon.co.uk/product-reviews/B009SJCX68/ref=cm_cr_pr_btm_link_next_5?ie=UTF8&pageNumber=5&showViewpoints=0&sortBy=bySubmissionDateDescending
While it's a long thread... [snip quotes and head-counts -- ask for them if you care]. Guessing aside, and amazon reviewers aside -- when you read these instructions, translated from the Russian, and then further patched up later on, does it *really* sound like something Aunt Tillie(tm) could handle by herself:
1. When you turn on the laptop and press F2 to enter setup BIOS.
2. In BIOS'e, tab Boot, change the value of Secure Boot for Disabled (and the system will issue a warning, click OK).
3. Will be extended OS Mode Selection, select "UEFI and Legacy" OS (and the system will issue a warning, click OK).
4. Press F10 in the dialog box, select Yes (the laptop will reboot.)
5. Press F2 and enter in the BIOS.
6. In BIOS'e, tab Boot, select Boot Device Priority and F5/F6 keys to set the required boot device to the top of the list. Update: You should see your USB stick listed and you can put it to the top of the boot order (my defaulted to be the 1st device anyway). Update: make sure your USB stick is NOT in one of the blue USB 3 ports. It will NOT work if it's in a USB3 port.
7. Press F10 in the dialog box to select Yes (the laptop will reboot.)
8. In BIOS'e laptop, tab Advanced, disable Fast Bios Mode, save the settings (F10-> Yes), exit the BIOS and then will be available to download from USB. To boot from the CD, paragraph 8, you can not perform.
Not mentioned in the instructions -- burn your bootable usbkey and insert it into the non-usb3 port at the appropriate point! More importantly, to my mind, no mention of how to re-configure SecureBoot with your own pubkeys (or your distro's pubkeys). Just straight from win8 into InsecureBoot, which gives Linux a bad name.
Re: SecureBoot setting, versus SecureBoot philosophy
1) Insert USB stick
2) Turn on computer
3) Hold down shift, click power icon, select restart
4) Select "Use other devices"
5) Select the USB stick
which is *exactly the same thing you do on any other Windows 8 system*.
Re: SecureBoot setting, versus SecureBoot philosophy
(Anonymous) 2013-09-01 06:59 pm (UTC)(link)Tony says: ...neither of them works or has any effect at all. You put in your usb, and it is just totally ignored. TOTALLY IGNORED!!!!! As I say, if you read the article I have recommended, you will see that this is intentional on microsoft's part, unless your software has a recognised cryptographic signature from microsoft... regarding the 'official' (but actually USELESS) method ...press Shift while pressing the RESTART button, NOT the shut down button.... #2) Use a Device... we then get a new screen... Icon 1&2 - UEFI: IP4&IP6 Realtek PCIe GBE Family Controller [and nothing else -- no bootable usb or bootable dvd shown -- just the PXE-or-somesuch gigabit ethernet chipset is available besides the main hdd] ... it just dont' frigging work!!! ... I have spent days trying to sort it out and get it working, but to no avail.
The person before him (Ioan) was able to install win7 on the laptop model in question, via the hold-shift-in-win8-when-you-click-restart procedure. Not sure whether from dvd or from usb, but win7 is also a microsoft OS, so methinks that is not a fair test. (Question: when you have a SecureBoot-enabled machine with Win8, and you attempt to boot from a Win7 dvd, does the SecureBoot infrastructure recognize your DVD *because* it is a msft-digisigned OS, or does the hold-shift-in-win8 procedure temporarily disable SecureBoot, or what?)
The people that commented further down in the thread, like R.Moss who I believe actually installed a non-microsoft OS, claimed they had to go through the quad-reboot quad-unset dance mentioned above, including disabling SecureBoot. I don't have the machine, so I cannot verify one way or the other. Maybe they were wrong, and simply hold-shift-in-win8-when-you-click-restart would have worked, too.
But the hold-shift procedure very clearly did *not* work for Tony... we can speculate on the underlying reason for this. Maybe he never plugged in his bootable USB, while still in win8, before holding shift? Maybe his bootable USB was not correctly burned, and not marked as bootable? Maybe the firmware bug, that this model refused to boot from a usb3 port, is what got him? (He had returned it to amazon by the time somebody mentioned this bug.) Note that Tony is a programmer (of unspecified sort). He knows about hdd partitions. He already knew how to boot from usb/cd, and burn usbkeys/cds, and install Linux. On older BIOS-based non-GPT non-UEFI non-SecureBoot boxen, that is! He also has the entire internet at his disposal, including your own github repo (which he admitted was totally over his head... but he *did* look at it during his days of effort, which is more than some hypothetical Aunt Tillie would have done).
Re: SecureBoot setting, versus SecureBoot philosophy
None of the above. It recognises it because the UEFI firmware presented it as a potentially bootable device. If you attempt to boot off it with Secure Boot enabled, and if it's not appropriately signed, the boot will fail.
Re: SecureBoot setting, versus SecureBoot philosophy
(Anonymous) 2013-09-01 07:33 pm (UTC)(link)Along the same lines, presumably there are *some* sorts of nominally bootable media that UEFI firmware would not actually recognize as bootable? Such as a 1.44 floppy with MSDOS, or perhaps MBR-style partitions, or ZIP-disk style partitions? What are the limitations here? Are the documented somewhere, or are they firmware-specific, i.e. the Samsung firmware will not recognize (say) GPT on usbkey in a usb3 port, but some other vendor's firmware might do fine?
Re: SecureBoot setting, versus SecureBoot philosophy
Re: definition of "potentially"
(Anonymous) 2013-09-01 08:08 pm (UTC)(link)The second step, is that the device must be recognized as "potentially bootable", i.e. if you have a DVD drive, but no DVD inserted, that will be rejected... even though in theory, you could power down the machine, and insert the DVD before rebooting. (This is a case where the definition of 'potentially' seems far too strict, in existing implementations.) On the other hand, if you have a DVD drive, with a bootable DVD inserted, it might be seen as potentially bootable... even though the signing key will fail to pass SecureBoot. (This is a case where 'potentially' is defined far too loosely, to my mind.)
Where do I find out the gory details, about exactly what constitutes a "potentially bootable" dingus, and what does not, for typical Win8-associated firmware? Nothing relevant pops out at me over here -- https://docs.fedoraproject.org/en-US/Fedora/18/html/UEFI_Secure_Boot_Guide/index.html -- this is a draft doc by Eric Christensen, last modified March 2013.
Re: SecureBoot setting, versus SecureBoot philosophy
(Anonymous) 2013-09-01 07:07 pm (UTC)(link)To me, it sounds like the combination of SecureBoot/GPT/UEFI infrastructure changes, coming all at once, is often too confusing even for reasonably savvy endusers that *already* know how to use Linux. Furthermore, that many changes at once is also leading directly to buggy firmware from manufacturers like Samsung (cannot boot from usb3 port in Tony's case... and lots of variation by vendor and model in the general case mentioned in comments below), and buggy tech-support scripts ("downgrading to Ubuntu will void your warranty"). Both of these trends directly benefit Windows: if even the geeks cannot get Linux to install without hours of effort and/or without disabling SecureBoot, and if firmware bugs don't impact win8 but do impact everything else, that's just peachy. Now, obviously, not everything is about Linux... part of the reason that GPT, UEFI, DDR3, and friends were introduced was to further winnow down the WinXP ranks. Planned obsolescence is not just for hardware, after all, with proprietary sockets for every generation of CPU and every generation of RAM; it's for software generations, as well.
So, although I think you're correct, that *probably* there was a way to install Linux on the laptop in question, I also think that Tony is correct: "...there is some activity there, which, if not actually illegal (and anti-competitive IS actually illegal) is certainly not quite right. Thanks for listening. Listen, at the end of the day, it is your money - you buy what you want. But I just want to explain things which no one else is talking about, and which there is NO MENTION of on the specs that are given for the machine when you are thinking to buy it. At least now, you have a more informed position from which to make your choices."
Tony's goal is to warn other consumers. My goal is to figure out a better pathway to getting F/L/OSS into the mainstream, for distro developers. So, if I don't like the current way that booting from USB works on new Win8 boxen, I should propose a new&improved way.
Re: SecureBoot setting, versus SecureBoot philosophy
The "Use Windows to choose your boot device" process is significantly more consistent than the old "Go into your firmware and find the option that tells it to attempt to boot from USB" process. From that perspective, yes, I think it's an improvement.
Re: SecureBoot setting, versus SecureBoot philosophy
(Anonymous) 2013-09-01 07:24 pm (UTC)(link)It is not obvious to me. Please elucidate. Tony never booted from USB, but he was trying to boot from a Linux usbkey and/or cdrw. The guy who did get it working, using the normal shift-restart trick, but was not booting Linux -- he was booting the win7 installer (not sure if from dvd or usb).
Isn't the list of available boot-devices you see in option#2 dynamically generated? With secureBoot enabled in the firmware, wouldn't it reject any non-msft-digisig'd media as 'non-bootable'?
The folks that *did* manage to install Linux used the old-school approach (go into the bios and mess with settings... including disabling SecureBoot amongst others).
Re: SecureBoot setting, versus SecureBoot philosophy
No.
Sure-Fire Way To Install $OS_OF_YOUR_CHOICE
(Anonymous) 2013-09-01 07:18 pm (UTC)(link)1. download a bootable usbkey image of the distro of your choice
2. burn it (preferably straight from the browser with no save-then-locate-then-open-burner-app steps), without overwriting any data already on the usbkey in question
3. if still booted into win8 on the target device, tells you to save & close & reboot ... but booting into win8 on the target device is *not* in any way required, you can always use a usbkey/dvd/cd/whatnot that you created on some other system, or purchased, or whatever
4. upon booting the target device, the bios autodetects multiple bootable media (internal drive + external usbkey ... and supports booting from usb3 as well as from usb2 might I add), automatically *asks* you whether to boot from internal hdd/ssd or from new usbkey/cd/dvd (not forcing you to hit F12 or somesuch... although by default there can be a 15-second countdown and then it boots from the internal media), offering appropriate names ("original win8" versus "new linux $DISTRO installer" rather than hardware-chipset-names). If there is a SecureBoot blockage, the BIOS warns you of the trouble, but when you confirm you want to install Linux anyways, makes it *easy* for you to add the new digisig into your device, preferably pulling it automagically straight from the linux boot-media ... much like a firmware-flash-update but less drastic. (Ideally it would also help you create a personal self-signed digisig, but that is above and beyond the call of duty.)
5. upon selecting the linux installer, and getting confirmation, it automagically clonezillas your existing setup, automagically uses parted to adjust your internal hdd/ssd appropriately, installs grub, automagically installs your distro for you with appropriate defaults, downloads the latest security patches from the internet, sets your timezone using geolocation, detects your lang&keyb from the bios/win8 installation, and *then* takes you into the full distro for 'final configuration' steps (no rebooting required)
6. this final stage might involve uninstalling some of the auto-packages, or adding some non-auto-packages, or just tweaking settings (plus confirming the automagic choices made during silent-install were not borked).
Obviously, this one-size-fits-all approach is no good for sysadmins at a large ISP, or developers working with complex hypervisor setups, or what not... but those folks can take care of themselves (and putting this Tillie-infrastructure in place will help the tech-savvy folks do *their* job more efficiently as well as making it *easy* for Tony to get his laptop booting Linux -- no muss and no fuss).
Re: Sure-Fire Way To Install $OS_OF_YOUR_CHOICE
The firmware doesn't do this.
The firmware and system vendors had no interest in doing this.
So yeah, it'd be easier if things worked that way, but they don't and they're not going to.
Re: Sure-Fire Way To Install $OS_OF_YOUR_CHOICE
(Anonymous) 2013-09-01 07:45 pm (UTC)(link)As you point out, the firmware vendor (AMI and friends) and system vendors (Dell/HP/Lenovo/Samsung/friends) were against such things, back when the current firmware spec-standards were developed. And I agree that getting anything changed under win8 is not-gonna-happen-no-way-no-how. I'm more interested in a few years from now.
Besides the Linux distros, there are other interested parties that might support some variant of my easy-to-add-new-digisig proposal, circa 2015. By then, google will have Android slash ChromeOS pushing into the mid-range laptop market. By then, there will be at least four major tablet OSes: win9, iOS, android-slash-chromeOS, ubuntuTouch-or-waylandPi, and at least *some* consumers will want the ability to crossgrade amongst those choices, rather than be stuck with a phone or tablet that won't be upgradeable. That's the biggest takeaway from the Tony-thread: plenty of people were mad that they *thought* the machine might be locked down that way, whether it was technically true or not. (Contrast that with the world of smartphones, where locked-down iPhone never used to raise eyebrows. Maybe that sentiment is shifting?)
Part of the reason that Linux got the short end of the stick in UEFI/SecureBoot was because we were reactionary, not proactive, methinks. I'd like to fix that, next time around.
Re: impedance-matching requirements when booting Linux
(Anonymous) 2013-09-01 10:10 pm (UTC)(link)Along the same lines, your distro needs to be UEFI-bootable, which in particular means that it must be a 64-bit distro, so that it will be compatible with a 64-bit UEFI firmware. Caveat, there are some cases where 32-bit [U?]EFI firmware exists -- cf this post by mjg discussing apple hardware like that -- http://mjg59.dreamwidth.org/26734.html Just because your 64-bit CPU is able to handle running a 32-bit OS, does not mean your 64-bit UEFI will be capable of booting that OS.
There was also some complaining about UEFI firmware only being able to read certain filesystems, with FAT32 being the safest. Presumably this only applies to the bootloader portion of the system (i.e. GRUB) and not to the full OS partitions, but I'm fuzzy here.
It may also be necessary to utilize GPT, rather than MBR, but this is speculative. (Not even touching 4kb-sector-size....)
There are some reports in the wild that support for UEFI-boot varies by the type of boot-device: some boxen will not permit UEFI boot from DVD, but work fine from USB, whereas other boxen will not permit UEFI boot from usb3, but work fine from usb2 (seems backwards to me!). These firmware limitations will prolly resolve themselves at some point, but for now there are known issues.
Does anybody have a definitive list of these sorts of requirements slash limitations, preferably with plenty of gory details?
Re: 'use other devices' not always visible
(Anonymous) 2013-09-01 10:15 pm (UTC)(link)Apparently, there are cases where this win8-option is not even visible, until you fiddle with BIOS, usually. Links below report the problem for three laptops: Acer E1 571 (unsolved?), Asus N56VJ-DJ71 (mfg says turn off SecureBoot and enable CSM as a workaround), && Samsung Ativ 500T (worked well for most folks but at least one person did not see the menu-item at all -- workaround was to use F10 during boot to see boot-order-menu).
http://superuser.com/questions/528636/missing-use-a-device-option-to-boot-a-live-distro-from-usb-on-a-windows-8-uef
http://forum.tabletpcreview.com/samsung/53946-boot-usb-500t-3-print.html