Matthew Garrett

Don't like Secure Boot? Don't buy a Chromebook.

(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.

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)

The rationale for forcing uses to choose between security and freedom is because you can't provide both together.

One particular use case that is considered important to Chromebooks is: You should, as a user, feel comfortable and secure using one that you do not own. Perhaps it's a loaner Chromebook like Virgin America provided last year for people on their flights, or one provided by a hotel you're staying at (another pilot Google has run), or a public kiosk, etc.

A simple reboot of the device will show whether or not it is a trusted OS installed on it; this is why once the developer switch is toggled, the firmware will always give scary "OS IS UNTRUSTED!" warnings. All bets are off then: since the owner can manipulate the system, including disabling the verified filesystem, install key loggers, send your passwords to others, etc.

The middle-ground would be to semi-trust externally signed OS, for example permit additional signing keys to be added to the firmware so that it can verify that the non-Chrome OS kernel it's booting matches those keys to give the modding community some level of secure boot support.

You'd have to resolve the UI issue, making sure a user unaware of the concept of modding (my dad, for example) would be still aware that he shouldn't trust the device in its modded state. But also have some other level of UI for the modded device firmware not matching the additional keys, while also still supporting modders who flat out don't want to deal with secure boot.

Our firmware team, though I can't actually speak for them, support modding enough that this is probably more a case of getting people to agree on the right approach rather than flat-out denial. Though also you know how security people like to say No and get angry at you ;)

"The rationale for forcing uses to choose between security and freedom is because you can't provide both together."Freedom to use - you are correct. My employer, for example, doesn't give me complete freedom on their network. Neither does my bank.Freedom to know - you are incorrect. It is imperative that how security functions is known so that the owners, operators and other parties can be sure it actually works and will actually do what it claimed.So, for example, I know how SSH works. Doesn't do me a blind bit of good in accessing an SSH connection unless the owner has configured for me to use and given me the key/passphrase.

"You should, as a user, feel comfortable and secure using one that you do not own."If one does *anything* sensitive on a device one does not own, one is a blithering idiot. Even a network one doesn't own is suspect (hence VPNs, HTTPS etc). I don't think SecureBoot solve this the problem of nasties on a device someone else owns in any shape or form.

I can't beleive that MG wrote that. What utter nonsense. OMFG. So what you are saying is that indiviuals should trust XYZ corporation who can steal your data but not the themselves. Oh man give your head a shake.

I presume it relates to the first line. It's easy to misread. e.g. the USA (to pick an example) should become an Orwellian super-state, and sacrifice freedom (the very thing it was founded on) at the altar of security.

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 boot4. 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.

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.

It should also be mentioned that a Chromebook with disabled OS validation may be useful as a development machine, but it's certainly not something you would want to use on a day-to-day basis (or much less give someone without a technical background to use).

At least the new ones that don't have a physical switch require you to press ctrl-d on each boot (or wait a minute) while any other keystroke re-enables validation. You might imagine how inconvenient that can be.

It is possible to replace the keys in the Chromebook firmware and there is a script provided in Chrome OS that will do it at /usr/share/vboot/bin/make_dev_firmware.sh as well as more scripts in the verified boot source repository that will assist with generating new keys and signing kernel images.

The major inconvenience here is that the keys live in a read-only firmware region so you need to defeat the write protection first which involves opening the case. Of course devices are all slightly different in how they implement write protection -- some require removing a screw and others use a jumper -- and the specifics for each board are not documented well enough yet but that is something we can and will fix Real Soon Now.

Supporting a user-provided key in developer mode that would only boot user-signed kernels is something we hope to do for future devices, but it has not happened yet. It is certainly fair to complain that the process is rather painful right now.

It is also worth mentioning that the entire firmware stack is as open as possible so if someone is not satisfied with what is provided they can build their own. This is obviously only useful to a really small/brave set of people and, just as with replacing the keys, it means you will no longer be able to boot official Chrome OS images unless you were smart enough to back up the firmware first.

Most chromebooks when unlocked have a mandatory boot order with no change options. This starts with the SD card. Big advantage of SD card it can be set read only.

Place validating loader on SD card then set it read only insert itand you are done. No other boot device will run on most of them.

So yes users could possibly set the software they want to trust on lots of models of unlocked chromebooks. If boot loader for the sd card exists to validate. Remember the sd card has to be switched to read only after its configured.

Read only SD card on motherboard for OS or OS's secuirty auditing bootloader would have been many times better than the UEFI idea. Simpler update as well.

You wrote "Chromebooks are either secure and running Google's software, or insecure and running your software."

That's a sentence that could easily be taken out of context to imply something very different from what I think you meant. That is, given that sentence alone one might think you are suggesting that Google's software provides security while "your software" provides insecurity. And I think your intended meaning relies on an implicit assumption that's exactly opposite.

In fact, I think you are talking about two different kinds of security here, both of which are desirable. And you are pointing out that in Google's system both cannot be obtained simultaneously. The first security is that of a "validated boot", (firmware validates that system to be booted been signed with an installed key). The second is an "obeys my bidding" sort of security, (I've seen the code, I've modified it according to my desires, it doesn't contain any anti-features like spying, etc.).

Isn't the Chromebook's firmware Coreboot (http://www.coreboot.org/Samsung_XE550C22-H02US), not UEFI? This is an important note, since one of the benefits of Coreboot (http://www.coreboot.org/Benefits) is that it is Free software. Ultimately, which Chromebook did you use?

I applaud Google for letting users at least disable the validation verses a company like Apple that does not let you disable the validation on their ARM devices (iPod Touch, iPhone, iPad, Apple TV, etc.). I am typing this from an ARM Chromebook, and I love it. It is the most secure consumer OS available today on the market, and it is very inexpensive at that. If you ever want to tweak, you can do that too! I think that this is unfair criticism of Google who are trying to allow for options by allowing the disabling of secured boot.

You assume that the software from Google and Micrsoft is secure. I wouldn't be surprised if they are both spying on your actions while you use the computer. Therefore, only the Chromebook with dev mode will actually allow me to install software I trust onto the system. Much better than the Microsoft tablet.

Is this an attempt to justify the fact that you have been working to make secure boot workable for Linux? Or is it an attempt to criticise some developers you don't like who are working for Google?

No? It's an attempt to dissuade people from blindly recommending Chromebooks as an alternative to Microsoft's imposed Secure Boot setup.

Tell me one thing: in your history of using Linux, how many cases have you come across of a compromised kernel being used to boot a box?

More than once. The use of kernel modules as persistent rootkits is hardly uncommon.

Why are people suddenly all barking about secure boot? Has there been some massive security incident that nobody on earth knows about - except Microsoft and Google?

Secure Boot would be impractical to implement on BIOS systems, so the timing's largely down to the availability of alternative firmware implementations for x86. Embedded devices have implemented equivalent technology for years.

About Matthew

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