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)
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)
Resigning Drivers and other Blobs
(Anonymous) 2013-02-13 08:56 am (UTC)(link)It's great that Microsoft provides the infrastructure to sign our own code to deal with the bootstrap issue. But does this imply, that everyone also needs to to trust anything they sign? If not, do we have to trust anything Google signs on Chromebooks?
I think it is really important that the next UEFI specification mandates that, there is not only a uniform key/hash management application for the initial boot, but also that anyone providing the initial OS must also provide a way to replace signatures on binaries with those of custom keys.
IIRC, the format of a signed binary can only facilitate a single signature.
Why must a keep trusting /everything/ that Microsoft/Google, sign once I have my own key installed. I should be able to remove their key and either selectively white list (via hashes) or sign not only initial boot images but also specific kernel modules/drivers.
I'm fine with using your Shim for the initial setup, but then I want to install my Shim that I've built and that was signed by me. I don't want to trust NVidia's proprietary driver, but only nouveau that was signed by debian, fedora, .
I'm wondering whether this should be done within the uniform UEFI application. Theoretically I'm fine if can boot into a minimal system without all modules available but enough so that I can replace signatures in modules/drivers or enroll hashes for specific drivers that I decide to trust without trusting everything that was signed by the Microsoft/Google keys. But this minimal system should also have a consistent user experience that doesn't differ between the UEFI/OS implementations.
Does anyone have something like this on their To-Do list? And what would it take to put that on someones To-Do list... seriously. Until the User can practically control the trust chain, SecureBoot is not Secure, even if your effort have relieved the Restricted Boot issue a lot. Thanks again though for doing that for us!