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

Entry tags:

advogato,
fedora

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.

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)

Flat | Top-Level Comments Only

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

I think that is counter-productive, Matthew.

Just like I have a coreboot bias, you likely have an ever so slight UEFI Secure Boot bias, having worked with it for so long. You understand how Secure Boot works while most of our community - that is, the community of people desiring general purpose computers - may not.

You understand what Secure Boot could do for us, and you have spent an enormous amount of time trying to solve the problem of how Linux can fit into that structure. Your effort is phenomenal!

As you may know, I have been participating in the coreboot project since some 12 years. My experience there and in the security field tells me that it is absolutely critical for our community NOT to depend on any single boot verification structure, and certainly not one which is being deployed to let Microsoft decide what a computer says is secure and insecure.

Microsoft clearly isn't acting in our best interest.

Google is also acting in their own interest, but at the moment I feel that our community's interest in having control over our machine's firmware aligns well with Google's interest.

That's the reason to act fast against UEFI Secure Boot.

Unfortunately for you, your job is to act fast toward UEFI Secure Boot, to make it "just work" for Red Hat and friends. I have the utmost sympathy for you, in having to deal with that problem every day. It doesn't take reading your musings on how broken everything is, to realize that it is not too joyous work.

Google has developed their own x86 firmware based on well-known components such as coreboot and U-boot, and not only do they provide their customers freedom to root their hardware, they have also chosen to (use components such that they must) publish their entire firmware source code.

Google is clearly being vastly more progressive than the UEFI Forum and Microsoft.

But them doing something that is much better isn't why the Chromebook really does deserve to be recommended as an alternative to Microsoft's Secure Boot.

The Chromebook deserves to be recommended because it is doing something different.

The ideal solution for our community hasn't been productized yet - maybe not even developed yet. As you know, the majority of our community doesn't have experience with security with or without involving hardware, and even fewer have x86 firmware experience. I believe (I'm just naïve like that) this may change thanks to your work, coreboot's work, and Google's work. I think it must change.

the timing's largely down to the availability of alternative firmware implementations for x86. Embedded devices have implemented equivalent technology for years.

coreboot has facilitated implementation of equivalent technology for years, 15 years to be precise. For some reason, the UEFI Forum and Microsoft have chosen a different route. The UEFI Forum's and Microsoft's route is not helping our community, while Google's route is.

That's why it makes sense to recommend a Chromebook, to anyone who is concerned about their machine's firmware, and the future of general purpose computing.

Secure Boot and equivalent technologies are only benefits to our community when the user can choose who to place their trust in. I don't want to have to place my trust in Microsoft or Google. And, right now, I'm guaranteed to have the opportunity to make that choice on x86 UEFI systems, and I'm guaranteed not to have that choice on a Chromebook. I hope that the situation will change in the future, but at the moment buying a Chromebook isn't a vote for user control.

right now, I'm guaranteed to have the opportunity to make that choice on x86 UEFI systems, and I'm guaranteed not to have that choice on a Chromebook.

You actually have much more choice with the Chromebook, because not only does it come with the developer mode which allows you to replace all of the system including the firmware - it also runs a firmware whose source code Google contributed to coreboot nearly a year ago.

No, developer mode doesn't allow you to replace the firmware. You need to remove the write protection on the flash, which is a very warranty-voiding exercise.

Consider that you are talking about a sub-$200 computer that's probably pretty darned reliable. You are crying over spilled milk.

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.

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.

You don't need to replace the UEFI firmware in order to replace the keys. You do need to replace the Chromebook firmware in order to replace the keys.

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.

The script that reads the existing firmware image, modifies it and then writes it back? How is that not replacement?

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?

I would greatly prefer to be able to replace the SMM code on my system, but at some point you're trusting somebody - have you verified your CPU microcode? What does firmware source code buy you if you can't check whether your CPU is actually executing it?

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?

The firmware code is available in a well known instruction set and, if I'm willing to spend an extended period of time working on it, I can verify that it's not doing anything nasty in SMM. The impact on a vendor of a user discovering that would be pretty huge. The CPU? That's a massively harder problem to solve.

But yes, my biggest problems are that there's no mechanism for anyone else to get their code signed by Google and it's excessively difficult to install user keys. Is there an actual requirement from Google that vendors have jumpers for disabling the write-protect, or is that just an artefact of manufacturer production and testing processes?

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.

Flat | Top-Level Comments Only

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

Everything that glitters isn't Secure Boot

Re: Everything that glitters isn't Secure Boot

Re: Everything that glitters isn't Secure Boot

Re: Everything that glitters isn't Secure Boot

Re: Everything that glitters isn't Secure Boot

Re: Everything that glitters isn't Secure Boot

Re: Everything that glitters isn't Secure Boot

Re: Everything that glitters isn't Secure Boot

Re: Everything that glitters isn't Secure Boot

Re: Everything that glitters isn't Secure Boot

Re: Everything that glitters isn't Secure Boot

Re: Everything that glitters isn't Secure Boot

Re: Everything that glitters isn't Secure Boot

Re: Everything that glitters isn't Secure Boot

Re: Everything that glitters isn't Secure Boot