[personal profile] mjg59
(Edit: It's been suggested that the title of this could give the wrong impression. "Don't like Secure Boot? That's not a reason to buy a Chromebook" may have been better)

People are, unsurprisingly, upset that Microsoft have imposed UEFI Secure Boot on the x86 market. A situation in which one company gets to determine which software will boot on systems by default is obviously open to abuse. What's more surprising is that many of the people who are upset about this are completely fine with encouraging people to buy Chromebooks.

Out of the box, Chromebooks are even more locked down than Windows 8 machines. The Chromebook firmware validates the kernel, and the kernel verifies the filesystem. Want to run a version of Chrome you've built yourself? Denied. Thankfully, Google have provided a way around this - you can (depending on the machine) either flip a physical switch or perform a special keystroke in the firmware to disable the validation. Doing so deletes all your data in the process, in order to avoid the situation where a physically present attacker wants to steal your data or backdoor your system unnoticed, but after that it'll boot any OS you want. The downside is that you've lost the security that you previously had. If a remote attacker manages to replace your kernel with a backdoored one, the firmware will boot it anyway. Want the same level of security as the stock firmware? You can't. There's no way for you to install your own signing keys, and Google won't sign third party binaries. Chromebooks are either secure and running Google's software, or insecure and running your software.

Much like Chromebooks, Windows 8 certified systems are required to permit the user to disable Secure Boot. In contrast to Chromebooks, Windows 8 certified systems are required to permit the user to install their own keys. And, unlike Google, Microsoft will sign alternative operating systems. Windows 8 certified systems provide greater user freedom than Chromebooks.

Some people don't like Secure Boot because they don't trust Microsoft. If you trust Google more, then a Chromebook is a reasonable choice. But some people don't like Secure Boot because they see it as an attack on user freedom, and those people should be willing to criticise Google's stance. Unlike Microsoft, Chromebooks force the user to choose between security and freedom. Nobody should be forced to make that choice.

(Updated to add that some Chromebooks have a software interface for disabling validation)

Why's it not in the spec

Date: 2013-02-04 09:25 pm (UTC)
From: (Anonymous)
Why was the user freedom (or whatever you want to call it) not written into the spec? Seems to be easy enough to do:
1. The user must be able to disable SecureBoot (but only by physical access)
2. The user must be able to install their own keys (but only by physical access)
3. UEFI must be passphrase protected, and the default must be changed by the user on first boot
4. It must be possible to do a factory reset (but only by physical access)
Seems to about cover everything. So why wasn't it in the spec? It's not like you buy a Ford and the manual says "If you don't use BP fuel, we will shoot your puppy".

Hmm...actually...I strongly suspect I know why it wasn't written into the spec. It was done to protect revenue, not to protect users.

Re: Why's it not in the spec

Date: 2013-02-04 09:37 pm (UTC)
From: [identity profile] pjones.id.fedoraproject.org
It's not written in to the spec for fairly straightforward reasons - UEFI as a body is really only empowered to specify mechanisms, not how they're used. That's the power the hardware (and software) vendors give them.

MS gets the power to specify how the mechanism is used, because MS is in a market position to make that kind of demands and back them up with their marketing dollars. UEFI has no economic carrot, nor a stick, which is why UEFI wasn't (very) widely deployed on systems until MS said vendors had to to get Windows 8 marketing money.

Re: Why's it not in the spec

Date: 2013-02-05 03:10 am (UTC)
From: (Anonymous)
"It's not written in to the spec for fairly straightforward reasons - UEFI as a body is really only empowered to specify mechanisms, not how they're used."

sorry what?

How can you specify mechanisms without considering how to control them?

A mechanism IS the considered implementation of control

You must mean standards?

Re: Why's it not in the spec

Date: 2013-02-05 03:36 pm (UTC)
From: [identity profile] pjones.id.fedoraproject.org
The specification is written by a body comprised of (mostly) hardware vendors. The language that makes it into the spec is the set of things all the vendors can agree on.

The result of this is that the spec only reflects the tools the vendors can use - the mechanism. It says "there's a list of keys here, and it's used for this", but it doesn't say what keys are in the list, because it's not possible to get cross-vendor agreement on that. Some will want some things, some will want others. This is especially true with enabling vs not enabling - you can't put that in the spec, because the spec has to reflect multiple operating systems, some of which won't support SB, and vendors shipping only those OSes won't vote to allow such a thing.

This is how cross-vendor standards work. It's a lowest-common-denominator system, even when you're standardizing new things. And because one version of Windows won't support SB and one will, machines shipping the old one must have it turned off, and machines shipping the new one must have it turned on - and the place that's controlled isn't the UEFI spec, it's the marketing considerations for the newer version of windows.


Matthew Garrett

About Matthew

Power management, mobile and firmware developer on Linux. Security developer at Google. 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