[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)

Re: Everything that glitters isn't Secure Boot

Date: 2013-02-06 12:31 am (UTC)
From: (Anonymous)
Consider that you are talking about a sub-$200 computer that's probably pretty darned reliable. You are crying over spilled milk.

Re: Everything that glitters isn't Secure Boot

Date: 2013-02-06 01:04 am (UTC)
From: [identity profile] peter.stuge.se
developer mode doesn't allow you to replace the firmware. You need to remove the write protection on the flash,

You're perfectly right about that! Sorry for my mistake. :(

which is a very warranty-voiding exercise.

That is not at all clear. The machine does need to be opened (how many screws are there?) but removing the write-protect seems to involve simply moving a jumper or a screw. How will Samsung react to a warranty claim? I guess they will just fix it for you.

My point still stands however; the Chromebook deserves recommendation for the simple reason that it is not going the UEFI Secure Boot route.

Re: Everything that glitters isn't Secure Boot

Date: 2013-02-06 04:35 am (UTC)
From: (Anonymous)
I haven't worked with UEFI in quite a long time. When you say 'replace the firmware', what do yo mean by that? The entire firmware including the reset vector and all code to initialize the hardware (memory training, etc)? I didn't know UEFI is allowing an end user (as long at the code is signed) to completely replace the system's firmware. I also wasn't aware that vendors were open sourcing their reference code in an open source fashion so an end user could build their own firmware.

Re: Everything that glitters isn't Secure Boot

Date: 2013-02-06 05:02 pm (UTC)
From: (Anonymous)
That is untrue. The issue your post doesn't discuss is that the ChromeOS security model relies on hardware write-protect to the flash chip containing the firmware as the core in it's security model, so you need to disable the hardware write-protect and then run the script that Duncan posted in the comments above (/usr/share/vboot/bin/make_dev_firmware.sh) to get the ChromeOS firmware on with whatever keys you specify as an argument to the script. The ChromeOS team's biggest problem here is not documenting this process better.

Re: Everything that glitters isn't Secure Boot

Date: 2013-02-06 07:02 pm (UTC)
From: (Anonymous)
OK. Correct me if I am wrong, but the whole point of the original post was that one currently can't replace keys very easily on chromebooks without disabling the write-protection on the flash part. Maybe I missed it, but it would have been more straight forward and clearer if this was directly called out as being the thing you are concerned about.

I am curious as to why you aren't concerned about who owns the firmware that actually runs on your systems. An SMM handler could easily be installed to snoop your information and do with it was it pleases. What does secure boot or verified boot buy you if you can't inspect/trust what is actually running on one's system?

Re: Everything that glitters isn't Secure Boot

Date: 2013-02-06 07:13 pm (UTC)
From: (Anonymous)
Agreed there is a point where one has to instill trust in some entity. That said, cpu microcode is miles away from trust the blob that initializes the system hardware. You can get a secured boot for your kernel, but aside from that there isn't much guaranteed.

As for my original question: your biggest concern with chromebooks is the high barrier for replacing keys so that self-signed kernels can be used?

Re: Everything that glitters isn't Secure Boot

Date: 2013-02-06 07:23 pm (UTC)
From: (Anonymous)
I'm not sure about it being a requirement. However, I would imagine for debug and development it is likely a requirement for the developers.


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.

Expand Cut Tags

No cut tags