[personal profile] mjg59
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.

Date: 2013-03-27 01:37 am (UTC)
From: (Anonymous)
We *were* campaigning against Restricted Boot 10 years ago, when it went by names like "Palladium" and "Trusted Computing". Some people argue against Secure Boot just because it smells like what those abstract technologies we fought against years ago. Some argue against it because it's a single brand for both FSF's "Secure Boot" and "Restricted Boot" concepts, and it's almost impossible to argue against one and not the other unless your target audience already knows enough of the technical details that you hardly need to argue.

Date: 2013-03-27 03:02 pm (UTC)
From: (Anonymous)
Yes, you *were* campaigning against Microsoft. However, when Apple implemented the Palladium spec to the letter, most people folded because they were more anti-Microsoft than pro-freedom and were taken by the shiny stuff. Now it is acceptable to the public to buy locked down devices.

Date: 2013-03-27 03:51 pm (UTC)
From: (Anonymous)
Trusted computing isn't "restricted boot", even by the FSF's definition above:

Can you completely disable the TPM? Yes
Can you run any software you'd like? Yes

Even if you opt-in:
Can you choose which keys you trust? Yes
Can you choose your root of trust? Yes

Kent Yoder

Date: 2013-08-29 03:27 pm (UTC)
From: (Anonymous)
The actual FSF definition of an abstract-but-nominally-UEFI-based SecureBoot (as opposed to non-UEFI plain old legacy boot which they also define) is this: "sure-fire way" for the enduser to be able to install Linux/etc on the device, themselves, with keys they select and trust, themselves. See the fsf.org link in second paragraph of the original article.

I would argue that the current approach does not qualify as a "sure-fire way" to freedom, no matter how we interpret that phrase: what we have right now is RestrictedBoot-on-by-default, but if you are savvy enough to figure out details of your particular firmware via the internet, in an hour or two you can jailbreak your machine and get it back into PlainBoot and/or actual-UEFI-style SecureBoot.

Unfortunately, the FSF definitions omit the use of adjectives like easy / obvious / userFriendly / simple / straightforward / wellDocumented / completelySupported / noGooglingRequired when they talk about the good kind of SecureBoot, as they were imagining it in the abstract. (The FSF article in question was written before hard details of UEFI-in-practice were known, methinks.)

Not my freedom

Date: 2013-03-27 08:36 am (UTC)
From: (Anonymous)
"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."

And that's the point which you keep to make although you have experienced the complicated problems secure boot introduces and which I don't buy. The problem with your definition of freedom is that you are almost ignoring the prerequisites towards the user. When he chooses to buy a machine coming with windows or just has a windows certification, John Doe does not know about Secure Boot or how to install his own keys, neither is there easily understandable documentation where he could educate himself how to do it, because that way is not standardized. It is a bit like if everybody would be born with handcuffs on and only if you pay a certain amount of money you get released and arguing that in this scenario everybody's freedom is respected and no harm is done, because everybody can remove their handcuffs if they just invest a bit of time.

Just because Secure Boot (the UEFI scheme, not the principle of authenticated boot) is not as bad as other abominations does not mean that we should not fight it, but I agree we should fight restricted boot schemes harder.

Re: Not my freedom

Date: 2013-03-27 03:00 pm (UTC)
From: (Anonymous)
If John Doe is unable to turn off a simple setting in BIOS, can you trust him to be able to change the boot order and install and configure Linux and partition disks without deleting his data?

Re: Not my freedom

Date: 2013-03-27 06:44 pm (UTC)
From: (Anonymous)
Yes. Many systems boot from CD by default. And if it's a new computer John doesn't care about parititoning, most modern linux installers will auto-partition the drive for you.

Re: Not my freedom

Date: 2013-04-01 03:47 pm (UTC)
From: (Anonymous)
This not the point - the whole idea of restricted or secure boot is basically wrong. Can you be sure trusted keys are really safe - the answer no you can't!

The only thing a secure/restricted boot can protect you from is if you have allowed something bad on to your system, and I suspect the bad guys will find a way round this.

Its all about protecting walled $ gardens and in by book its wrong, I own the hardware and I should not be restricted period!

Let the user choose

Date: 2013-03-27 06:31 pm (UTC)
From: (Anonymous)
As far as I'm concerned, the kerfuffle betwixt "sercure" boot, and "restricted" boot is a digression from the main issue, whether or not users control their own systems, that they have purchased, and hence own. If they own them, then THEY should have all control over how the system is to be configured or behave. I they don't, then they are only RENTING their computer systems. Anything else, is a distraction. So, do we OWN our systems, or do we NOT?

Re: Let the user choose

Date: 2013-08-29 02:10 pm (UTC)
From: (Anonymous)
I think saying SecureBoot==buyerControl && RestrictedBoot==sellerControl is too simplistic. The born with handcuffs example another poster mentioned a couple comments up from here is relevant.

When the baby is born, some Evil Adversary(tm) has to jump in and put on the handcuffs. From that point forwards, the formerly PlainBaby is now just a RestrictedBaby. When the parents get it home from the hospital, they can go on the internet, and learn about how to pick the lock on the particular model of handcuffs their baby was imprisoned with, and after a couple hours or so of wasted effort (assuming they don't need a BIOS mod to the handcuff firmware to overcome some 'accidental' bug or 'security' misfeature). At that point, and only at that point, do the parents have SecureBaby... assuming they put handcuffs of their own choice in place, with handcuff keys only they have, and not the adversary. (The parents might also opt for PlainBaby, with no handcuffs at all.)

I hope the metaphor is clear: PlainBaby is non-UEFI boot, SecureBaby is UEFI-boot with parent-aka-enduser-supplied keys, and RestrictedBaby is what you get from the hospital-aka-factory. But it seems a pretense to say that the enduser is in 'control' of their *plain* hardware device, when it ships by *default* with RestrictedBoot, just like it seems obviously wrong to say that the parent is in 'control' of their baby when the Evil Adversary with dibs on the hospital grounds swoops in to apply the handcuffs and turn a *plain* old baby into a RestrictedBaby.

The application of RestrictedBoot to a product, without the enduser's getting to say whether they want it or not, and if so what *sort* of security they want, is like the application of handcuffs to newborns, without the parents getting the handcuff keys immediately (or the option of no handcuffs whatsoever!). The reason some folks -- not me personally since actually I would love to have RestrictedBoot applied straight from the hardware-factory which only permits software to install if it has been signed with my personal pubkey i.e. no win9 and no bloatware and no trialware and so on -- but the reason some folks complain about SecureBoot just as loudly as they complain about RestrictedBoot is that, invariably from what I have seen, it works just like the handcuff model.

The enduser has to *work* to get the wrong keys out, and the right keys in. The evil adversary gets what they want for free ... by default ... and the public at large, not savvy in the ways of lockpicking, eventually gets used to the idea that all iPhones, then all tablets, then all PCs just *ought* to be locked-down vendor-software-only disposable-every-six-months special-purpose kiosk-devices for content-consumption and spyware and nothing more.

So, while I agree with your technical stance on SecureBoot as a conceivable advantage, I think you're missing the bigger picture. Namely, that whether you call it SecureBoot that the savvy consumer can bypass, or RestrictedBoot that the savvy firmware-modder can bypass, they are in the same basic category: bad things the evil adversary did, before you had a chance to stop them, and now must be undone, or lived with.

Hint -- if 98% of the population lives with it, then the marketshare of Linux on the PC will be 2%... just like now. When you buy a PC that comes pre-installed with Win/iOS/bloatware, you have 'freedom' to undo that stuff, and install what you really wanted in the first place. But there is a difference between freedom without intentional freedom-blocking-hinderances installed at the factory by default, and the *true* situation we live in.

I'm not saying you're wrong, mjg. SecureBoot *is* distinct from RestrictedBoot, for those of us paying close attention. But when what you get from the factory is invariably RestrictedBoot by default, and converting that state into *actual* SecureBoot requires hours or days or forever, depending on the difficulty of the out-of-support-contract firmware reconfig / not-well-documented firmware upgrade / unauthorized-and-warranty-voiding firmware mod, then you are not talking about freedom by default. You are talking about the possibility of jailbreaking... but the default should not be jail.

The default should be PlainBaby, or SecureBaby with keys supplied by the parents (and not copied at the hospital), because RestrictedBaby-by-default will someday soon lead to a world of RestrictedBaby-take-it-or-leave-it. We already live in that world with many phones, tablets, digicams, televisions, auto-puters, and whatnot. I want *that* world to get smaller and smaller, not grow and grow until it encompasses laptops and desktops and servers and everything.

Date: 2013-03-27 11:39 pm (UTC)
From: (Anonymous)
I never heard anyone talking about the following:

Say you want to dual-boot Linux and Windows 8

1. If you disable secure boot to be able to run Linux will Windows 8 still boot?

2. If Windows 8 will boot will it play protected content while secure boot is disabled or are all your multimedia purchases from Windows Store or other DRM sources inaccessible until you turn secure boot back on?

3. If you do not disable secure boot, but instead insert your own key will that erase secure key storage by default and thus remove Microsoft's key?

4. How complicated is to sign Linux kernel which you have compiled?

5. How does secure boot affect projects like linux from scratch, Hirens Boot CD, etc?

Date: 2013-03-27 11:53 pm (UTC)
From: (Anonymous)
Regarding #2, are you absolutely sure?

It is really hard to believe because all the efforts so far being made on locking down user's PCs were done with an intent of stopping piracy.

Regarding #3, what I really don't understand is how would you add Microsoft's key back? Where do you get it?

(no subject)

From: (Anonymous) - Date: 2013-03-28 12:32 am (UTC) - Expand

Blue Pill

From: [identity profile] kevinkofler.wordpress.com - Date: 2013-03-28 02:24 am (UTC) - Expand

Re: Blue Pill

From: (Anonymous) - Date: 2013-03-30 03:10 am (UTC) - Expand

Re: Blue Pill

From: (Anonymous) - Date: 2013-04-02 12:46 am (UTC) - Expand

Well said

Date: 2013-03-28 12:07 pm (UTC)
From: (Anonymous)
Thank you for your well reasoned explanation, sadly this sort of thinking and analysis has been missing from the debate.

Secure Boot is a good thing, with some implementation problems. Restricted Boot is horrible and should be legislated against
From: (Anonymous)
I have read several posts on the Net which highlight restrictive practices. I said this would happen and it has. Is anyone so blind as cannot see that Microsoft is not a nice company, no, in my opinion they are evil!

Here is just one post from a distressed customer of a Samsung product on which he finds:-
1. Secure boot cannot be switched off.
2. Booting is not possible on neither CD nor USB media

Look for the heading 'APPALLING - AVOID!!!'.
http://www.amazon.co.uk/product-reviews/B009SJCX68


From: (Anonymous)
Try here:

http://www.amazon.co.uk/gp/cdp/member-reviews/AIMQNB465APP9/ref=cm_pdp_rev_title_1?ie=UTF8&sort_by=MostRecentReview#R2PNZXLR9ZVL5H

Re: Restrictive practices: No it isn't always possible to install Linux !

From: (Anonymous) - Date: 2013-08-29 02:40 pm (UTC) - Expand

Re: SecureBoot setting, versus SecureBoot philosophy

From: (Anonymous) - Date: 2013-09-01 08:12 am (UTC) - Expand

Re: SecureBoot setting, versus SecureBoot philosophy

From: (Anonymous) - Date: 2013-09-01 06:59 pm (UTC) - Expand

Re: SecureBoot setting, versus SecureBoot philosophy

From: (Anonymous) - Date: 2013-09-01 07:33 pm (UTC) - Expand

Re: definition of "potentially"

From: (Anonymous) - Date: 2013-09-01 08:08 pm (UTC) - Expand

Re: SecureBoot setting, versus SecureBoot philosophy

From: (Anonymous) - Date: 2013-09-01 07:07 pm (UTC) - Expand

Re: SecureBoot setting, versus SecureBoot philosophy

From: (Anonymous) - Date: 2013-09-01 07:24 pm (UTC) - Expand

Sure-Fire Way To Install $OS_OF_YOUR_CHOICE

From: (Anonymous) - Date: 2013-09-01 07:18 pm (UTC) - Expand

Re: Sure-Fire Way To Install $OS_OF_YOUR_CHOICE

From: (Anonymous) - Date: 2013-09-01 07:45 pm (UTC) - Expand

Re: impedance-matching requirements when booting Linux

From: (Anonymous) - Date: 2013-09-01 10:10 pm (UTC) - Expand

Re: 'use other devices' not always visible

From: (Anonymous) - Date: 2013-09-01 10:15 pm (UTC) - Expand

Date: 2013-03-28 04:43 pm (UTC)
From: (Anonymous)
We are finding in Ubuntu Forums that a lot of variation by Computer Vendor and model.

Some work just the way they should and dual boot Windows 8 and Ubuntu without any issue.
Some require secure boot and the shim file works to boot Ubuntu.
But some seem to be hard coded to only boot /EFI/Microsoft/Boot/bootmgfw.efi. A work around is the rename shim to the Windows efi file and that works.
And some just do not seem to work at all. Not sure if user issues with all the new settings in UEFI menus or how UEFI is implemented.

Date: 2013-03-30 07:58 am (UTC)
From: [identity profile] steveriley [launchpad.net]
We're seeing similar experiences at Kubuntu Forum. In fact, I created a dedicated subforum just for UEFI. I've posted the results of a number of my own experiments, and folks are also discussing theirs. It's been helpful.

Date: 2013-03-30 08:00 am (UTC)
From: [identity profile] steveriley [launchpad.net]
Whoops, forgot the link.

http://www.kubuntuforums.net/forumdisplay.php?167-UEFI-assistance

Developer here

Date: 2013-03-31 03:04 pm (UTC)
From: (Anonymous)
Hi, mjg59. I've seen you presentation and I've really enjoyed it despite the fact someone in the public was a Professional Hater and didn't really seemed to understand who was giving the presentation...

Thanks you very much.

Profile

Matthew Garrett

About Matthew

Power management, mobile and firmware developer on Linux. Security developer at Nebula. Ex-biologist. @mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer.

Page Summary

Expand Cut Tags

No cut tags