"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." Good point.

You can easily turn SecureBoot off on a Chromebook, even the ARM version. Enable developer mode, and there you go. Can I turn that off on an RT tablet?
For me, what matters is not if the machine has a secure boot mechanism or not, it's whether I am the one in control of whether that feature is turned on or off. It's the same reason I don't mind OS X 10.8 being limited to signed apps by default: I can turn it off with a few clicks and the way to do this isn't even obscure or hidden. So, in the case of a Chromebook, I am the one in control of the feature, so it wouldn't bother me that it's there.

I actually think the title is plain wrong, it should be "Don't like Secure Boot? Buy a Chromebook." Since your choice is either secure boot and chromeos, or no secure boot and other oses. So really, if you don't like secure boot, chromebooks are good options.

"You can easily turn SecureBoot off on a Chromebook, even the ARM version. Enable developer mode, and there you go. Can I turn that off on an RT tablet?

So you didn't read the article. "

Actually he has a good point, depending on how you define security. I don't consider a Microsoft tablet with RT secure as Microsoft is likely watching what you do. The same with the Chromebook with its native OS. I don't care how impossible it is to bypass Microsoft's security protocols since I don't trust Microsoft to start with. I do trust open software that anyone can vet for privacy breaches. And the Chromebook with dev mode lets me set up a device I can actually trust.

It comes down to local security versus freedom of choice. If you want to choose to install your own OS, you must disable the security features of the firmware that prevent modified and/or unsigned kernels from being installed locally. You gain control over the hardware but lose the first line of defense. At that point it's up to you to harden your system, and if local security isn't a priority then you are left with a device not much different from previous generation x86 laptops.

Businesses primary purpose is to make money; the product is equity payments and the customers are the shareholders. Those shiney blinky light products are simply a tool used in producing the companies real product.

It's perfectly rational to expect vendors to exclude optional features. If managing and/or disabling secure-boot is an optional feature, you can be sure it'll be excluded to reduce production costs when maximizing profit margins.

It get's even better. Now you can claim that managable secure-boot is a premium feature only available in your high end products and you can charge the chattle more for the privaledge. You pull an even bigger profit margin out of the premium products passing that on to your real customers; shareholders.

Unless something has changed, manageable secure-boot is also only an option for Intel based machines so all those ARM based win8 machines are guaranteed not to include the option to allow hardware owner control over there purchased property.

Yet, all I could see in the linked article was that unlocking your chromebook bootloader will delete current user data. So, not at all different from unlocking an Android device; you do it right after purchase or take a backup of your data to restore after unlocking. "not a big deal" (tm)

Since you made the assertion that this is somehow enforced by Microsoft then I suggest that you do it sweetheart. I'm afraid you don't get out of it like that. As you should well know motherboard manufacturers have done, do and will do the absolute bare minimum and less to cut costs. They are not going to implement a modifiable key system that virtually none of their users use.....and you think Microsoft will complain about that?

I'm sorry Garrett, but I'm smelling you out as a sell-out as Sam Varghese has already done.

All the Windows 8 certified systems (including cheap ones) that I've looked at implement key management, either through an explicit UI or via returning the system to Setup Mode. You're the one claiming that the majority of manufacturers will ignore this requirement. If so, you should be able to buy pretty much any cheap Windows 8 certified motherboard and prove that it doesn't have this functionality. How about this: pick a random Windows 8 certified board off Newegg and link it here. Buy it and test it. If there's no way to install your own keys, I'll pay for it.

Heh. Let's put it this way, if there was any confidence in this then Linux distributions wouldn't be getting themselves key-signed by Microsoft, would they?

You will be reporting the demise of pretty much all key management on all but high-end systems on your blog in future and I will happily be around to point you back to this........ I haven't heard anything from you about how Microsoft is going to enforce this. Motherboards will have Microsoft's key and that's all that matters.

The only reason Secure Boot can be disabled is because of the massive amount of bootable software users and companies use and still need to use on their hardware - namely previous versions of Windows, imaging software and VMware - which will be dropped off the face of the map at a later date.

Chromebooks implement Secure Boot in the way that they do because it's more difficult to differentiate a legitimate user who has physical access and someone more malicious. I can understand it because of their function, but I hope Google will find a way to do it in future. Secure Boot on PCs will marginalise software you can boot and make hardware ridiculously expensive.

You also sail right over Windows on ARM which is a platform that has no such legacy problems for Microsoft and where you get absolutely no quarter given whatsoever. That's where we will end up.

There's no reason for a distribution to get itself signed by Microsoft if they're happy documenting how to handle key enrolment on every different firmware implementation. Many distributions aren't happy having that as a requirement.

I take it that you're not willing to take me up on my offer? You're the one who said that this functionality would only be included on the most expensive boards. If you're right, you get a free motherboard and the satisfaction of proving me wrong. If you're sure you're right, this should be a great opportunity.

...because the Chromebook is the closest thing left to a netbook we now have, after the category was killed and replaced by overpriced Ultrabooks.

It's a pity it sounds tricky to get a proper Linux distro on them, because Chrome OS is mostly useless without a Net connection and quite restricted on what you can run compared to a fully blown Linux. Some hardy souls have got Fedora booting from an SD card, but I'd rather have it booting from an internal SSD for speed reasons.

This whole UEFI business is just a wonderful example of how when you repeat a lie long enough, it becomes accepted truth. UEFI SecureBoot never was about boot viruses, though yes, it does make them very hard or near impossible. The whole point of this technology has always been to shift control over the software users install over to the hardware vendor.

MBR viruses have been a dead horse for at least 10-15 years now, ever since the web browser and its plugins became a much more lucrative target for malware. Please note that SecureBoot in no way prevents rootkits or kernel exploits - it's still the responsibility of the OS to verify all code it loads.

UEFI is just a whole bunch of new ways for your machine to fail or misbehave. If you think ACPI was bad enough, wait till you get a load of UEFI firmware bugs, such as DMA'ing network packets over a region of memory where it wasn't supposed to (causing random OS crashes), or, as in the case of Samsung, bricking your machine because some OS had the audacity to follow Samsung's own declared APIs. One Linux user of the samsung UEFI driver also reported that due to a UEFI firmware bug, installing Ubuntu caused Samsung's UEFI to overwrite its "Setup" boot entry with Ubuntu, blocking access to the firmware setup menu. On servers, it's an even worse plague - IBM servers with UEFI configuration menus now require mouse input in order to set up properly (it's still possible via the keyboard, but it's about as pleasant as walking over broken glass). And forget about serial console redirection - text terminals can't handle GUIs, so no remote recovery for you!

The BIOS was crap, but at least it was simple. It loaded into predictable locations, and all we needed was a simple set of BIOS extensions in well specified regions to provide new features. Instead, this UEFI crap was concieved of, with the spec itself over a motherfucking 2200 pages long. FFS, all parts of MPEG-2 are together less than 1000 pages long (the core systems+video+audio tech is < 500 pages), and that's a fully-fledged multimedia system. With a spec this long, it's no wonder firmware vendors (who are crap at producing even workable BIOSes) will produce terrible implementations.

MBR viruses have been a dead horse for at least 10-15 years now, ever since the web browser and its plugins became a much more lucrative target for malware. Please note that SecureBoot in no way prevents rootkits or kernel exploits - it's still the responsibility of the OS to verify all code it loads.

To install an MBR boot virus you'd need write access to the MBR (and it's extremely easy to detect if that sector has been modified). Also, the MBR boot virus would need to run in real mode while all sane OSs switch to protected mode (or long mode) and discard all of the real mode code, so an MBR virus can't easily do anything after the OS has booted. These are the things that makes an MBR boot virus a waste of time.

For UEFI, everything typically sits on a big FAT partition with no security whatsoever; and various parts of UEFI remain (and may be executed as privileged code) after the OS boots. These things combined mean that (without secure boot) UEFI is a massive security disaster.

The problem is who manages the keys. The EFI/UEFI specifications should have required that the computer's owner has complete control over all keys; and that OEMs, OS providers and the current user (if they aren't also the computer's owner - e.g. "disgruntled employee") has no control of any keys at all.

To install an MBR boot virus you'd need write access to the MBR (and it's extremely easy to detect if that sector has been modified). Also, the MBR boot virus would need to run in real mode while all sane OSs switch to protected mode (or long mode) and discard all of the real mode code, so an MBR virus can't easily do anything after the OS has booted. These are the things that makes an MBR boot virus a waste of time.

I didn't purport to explain all of the problems with MBR viruses. Yes, all you said is true, they are difficult to write, however, once installed (and if done properly), they are very difficult to detect (e.g. by manipulating the VM layout, you can trick the OS into thinking it's calling the BIOS, when its actually calling your crafted functions, allowing you to mask your presence). However, even in their hey days (we're talking DOS/Win3 early 90s), they were very few and far between.

For UEFI, everything typically sits on a big FAT partition with no security whatsoever; and various parts of UEFI remain (and may be executed as privileged code) after the OS boots. These things combined mean that (without secure boot) UEFI is a massive security disaster. Secure boot is an attempt to fix UEFI's huge gaping security holes. It's very necessary.

Well, it depends on the OS - if the OS doesn't allow you to modify this partition, then its over. It's not the choice of filesystem that makes a system insecure ("chmod -R a+rwx /" and you've got the same on a Unix machine, on Linux its easy to solve FAT's insecurity thusly: "mount /mountpoint -o remount,ro"). I'm not saying there isn't any value in SecureBoot - the evil maid attack is one example where it helps a lot - I'm saying that the reasons for UEFI's and SecureBoot's widespread adoption aren't to help protect users, but to transfer control over the machine from the user to the manufacturer and the security thing is just a cloak under which they want to hide it. News sites such as OSNews are doing users a disservice by not calling the vendors out on it at every opportunity. This isn't about securing your machine from attackers. It's about securing the machine from you, the owner.

The problem is who manages the keys. The EFI/UEFI specifications should have required that the computer's owner has complete control over all keys; and that OEMs, OS providers and the current user (if they aren't also the computer's owner - e.g. "disgruntled employee") has no control of any keys at all.

Yes, that would be part of the spec if it were intended to help users. My contention is that that was actually not the goal.

"I'm saying that the reasons for UEFI's and SecureBoot's widespread adoption aren't to help protect users, but to transfer control over the machine from the user to the manufacturer and the security thing is just a cloak under which they want to hide it. News sites such as OSNews are doing users a disservice by not calling the vendors out on it at every opportunity. This isn't about securing your machine from attackers. It's about securing the machine from you, the owner."

Your entirely right about the maligned corporate impetus behind secure boot, but why are you dissing OSNews in the process? I'm not suggesting OSNews be above criticism, but I don't really understand what your getting at here in saying they're doing users a disservice? IMHO this article was published precisely to highlight the secure boot OS prejudices that your alluding to.

Serious question: what would you have Thom do differently in covering the topic?

Your entirely right about the maligned corporate impetus behind secure boot, but why are you dissing OSNews in the process? I'm not suggesting OSNews be above criticism, but I don't really understand what your getting at here in saying they're doing users a disservice? IMHO this article was published precisely to highlight the secure boot OS prejudices that your alluding to.

"This could potentially complicate the installation of other operating systems, like Windows 7, XP, and Linux."

This isn't just the potential, it's the clear outright reason. There's no question about it, Secure Boot is just a vehicle to place control over your machine firmly in manufacturer's hands.

Serious question: what would you have Thom do differently in covering the topic?

Well, in this case, Thom's only words were "Good point", so there's really very little talk about.

In short, my problem is for cutting way too much slack to the vendors (both MS and OEMs) and playing the politically correct game in assuming everybody is in it with clean intentions. We know what their motivations are: to squash competition from free software. We even have the big guy, Gates, on the record on the previous crapware attempt at making free software and open-source difficult to install and use (ACPI).

I guess you could just call me tired of this theater. We know the players and we know their motives, because we've seen this movie play before. And yet the whole IT news space is going through the motions again and again.

I can understand why they're using Secure Boot like this given what they want the Chromebook to actually be. Wiping user data when someone (could be you, could be someone else) installs another system on it is something you actually want to happen and you certainly do if you're an organisation with remote workers with these machines all over the place.

The tricky part here is differentiating between a legitimate person who wants to modify his/her system and someone malicious with a stolen machine and keeping the actual security usefulness of Secure Boot intact for the end user.

I have never seen an answer from Redmond on that topic.

The notion that Chromebooks are more locked down that Windows 8 machines is bollocks.

Windows 8 systems and Chromebooks both default to only running signed software. Windows 8 systems and Chromebooks both permit you to disable all signature validation. Windows 8 systems permit the end user to choose to use their own keys instead of the vendor ones. Chromebooks don't. The user doesn't have the freedom to deny unwanted software from running on their system. It's a valuable freedom that Google don't currently provide, and it's completely fair to say that the Chromebooks provide less user freedom as a result.

is there a GUI to replace keys ? no (although there are scripts to do so). is it possible to wipe/replace the keys ? yes -- toggle the hardware write protect. thus you are provably wrong.

is the bios source released for *any* device shipping windows 8 ? pretty sure not. how about any mobo out there where the target is windows ? no ? how about chromebooks ? ignoring the first 3 devices, the code is published for devices since released (coreboot & u-boot and the embedded controller [ec] that manages the keyboard/battery/etc...).

so go ahead, download the source, build it & embed whatever keys you want, and flash the device. now you have a fully secure system where only you own the keys.

Once you're at the point of breaching your warranty and fiddling with the hardware, many things become more tractable. I suspect you'd have no trouble in modifying the keys on a Windows RT device, for instance.

Windows 8 systems permit the end user to choose to use their own keys instead of the vendor ones.

No, they don't. That is purely at the behest of the hardware manufacturer and you've provided nothing to back up that Microsoft will enforce this in any way. Stop repeating this crap.

You will be reporting on manufacturers not implementing modifiable key systems in no time, mark my words. The only reason you can disable Secure Boot now is because of the bootable software that users and companies still need to be able to run on current hardware.

Chromebooks don't. The user doesn't have the freedom to deny unwanted software from running on their system.

That's a curious way of putting freedom and a very curious way of painting what Microsoft is doing with this.

The FSF agree that this is a worthwhile freedom. It shouldn't be possible for any vendor to have more control over a system than you - that means that if the vendor can limit which software the system will run, you should also have that ability. The laptop I'm currently using gives me that ability. A Chromebook doesn't.

But still, let's find out how willing Microsoft are to enforce this. Find an example of a machine that doesn't let you install your own keys and I'll make sure Microsoft know about it, then we'll see what happens from there.

The FSF agree that this is a worthwhile freedom. It shouldn't be possible for any vendor to have more control over a system than you - that means that if the vendor can limit which software the system will run, you should also have that ability.

I'm curious that you're painting it this way, as others are.

When you're having to get yourself key-signed by Microsoft I find that statement rather laughable to be perfectly honest. I think you'll find the FSF does not agree with you that everything is absolutely fine.

Find an example of a machine that doesn't let you install your own keys and I'll make sure Microsoft know about it, then we'll see what happens from there.

This article seems to ignore the fact that Windows RT requires neither the ability to add new keys nor the ability to disable secure boot. Perhaps I haven't been paying enough attention, but my impression that most of the complaints are about the situation with Windows RT and not plain x86 (or x64) Windows 8.

The title is ironic because it implies only those who dislike secure boot have an issue, but it sounds like the chromebook gives the most trouble to users who'd actually want to have secure boot enabled while using a 3rd party OS.

This is one of the cases that I feared would happen, in fact most problems with secure boot were foreseen. The reality is that the feature was designed to be used by venders and not the end users, this really shows.

For an open standard like UEFI, owner control ought to have been *expressly* possible. It's disgraceful that the standard didn't require compliant implementations to enable owners to take control over their own hardware keys as they want to. As it stands, there's no requirement for owners to have access to their own hardware keys and it's only by the graces of anti-trust threats that Wintel owners have largely avoided a skirmish.

I hope there's enough public outcry on non-wintel platforms to pressure all vendors to open up Secure Boot on their respective platforms as well. Google, for it's part, is going to find itself in a tossup between it's role in standing up for open principals or behaving more like OS/hardware vendors who want to lock out end users & competitors.

I hope there's enough public outcry on non-wintel platforms to pressure all vendors to open up Secure Boot on their respective platforms as well.

chromebooks don't use UEFI SecureBoot, which is what Matt is whining about. ARM chromebook with locked down UEFI SecureBoot would probably be okay, as long as it's UEFI.

Fanboys are a weird bunch.

Google, for it's part, is going to find itself in a tossup between it's role in standing up for open principals or behaving more like OS/hardware vendors who want to lock out end users & competitors.

Lock out end users? You can install whatever firmware you want. chromeos verified boot (with your own keys), UEFI (with your own keys if you so desire), seabios for "normal" BIOS (on x86 chromebooks anyway).

They do lock out competitors - as commented in the comments to mjg's rant, the chromeos devs want to enable user installable keys in the default install.

That might solve it, or not. Depending on how they do it, that still won't help Redhat.
I don't care, it's about user freedom, not 1bio us$ revenue, 800lbs gorilla company freedom.

Yes, I'm grumpy. mjg praises UEFI SecureBoot, a closed standard of which all real-world implementations are closed sorce, as if it was his own invention, while ranting against other open source projects.

Ironically, I might be the first to release an open source x86 UEFI with SecureBoot soonish - mjg is best ignored IMNSHO.

Closed standard? It's a publicly available document. You don't need to pay any license fees. You get the right to use all the embodied patents. There's a complete implementation of the specification available under a free software license, including Secure Boot support.

I'm not in favour of any platforms locked to a specific vendor, but nor am I in favour of platforms where one vendor gets special control over what I run. If they're able to lock down my system, I want to be able to lock down my system.

There's a complete implementation of the specification available under a free software license, including Secure Boot support.

Except for some standard relevant parts (eg. FAT) which aren't under a free software license. And some parts that are plain missing (eg. SMP init).

I'm not in favour of any platforms locked to a specific vendor, but nor am I in favour of platforms where one vendor gets special control over what I run. If they're able to lock down my system, I want to be able to lock down my system.

You're able to unlock the system, then lock it down the way you want it. "Bring your own lock" is slightly more annoying than "Bring your own key" for distributors. For users it doesn't make much of a difference. In fact, I'd prefer to be reasonably sure that the old tenant is shut out completely, but I concede that I'm no average user when it comes to firmware.

The ChromeOS security model relies on having hardware write-protection over the part of the firmware which is used in early boot. If the user disables the write-protection, then it's very possibly to insert your own keys into the firmware image. There is even a script that ships on all ChromeOS systems which will do this for you at /usr/share/vboot/bin/make_dev_firmware.sh

The ChromeOS team's biggest problem here is not documenting this process better for each device. So far though, very few people have even asked how to do it.

The ease of disabling the write protection is also highly variable between different ChromeOS devices. For example on the Samsung ARM Chromebook, it is just a screw which needs to be removed. There's a tension between ease of removing the write-protect and security against "walk-by" attacks.

But the system wasn't intentionally designed to lock out the owner at all, which is what the blog post implies, and that is very unfortunate.