As a professional security guy in my day job, I have to say that it's not a terrible idea to create a system where only signed binaries can run. This is almost too inflexible to be usable on the desktop, but on the server you can sign everything during development/integration, so that your production environment has 100% signed and pre-arranged software with no chance for a virus to even execute.
This would be called a "defense in depth" strategy: our hope is that a web server (or any type of server) would be able to stop attackers at the front door, by preventing the web server itself from being compromised. Or even if it were compromised, ASLR would prevent them from finding the address of a library and writing shell code; they'd just crash the server with a segfault on their first pointer dereference or memory read.
But the reality is that really crafty, malicious hackers doing naughty things can bypass a lot of our front line defenses. So the hope is that a fully trusted, signed system would prevent execution of arbitrary code. I'm not sure how interpreters would work in this environment, though; anyone who could execute `python' (or inject commands into python using a web form or something) would have quite a lot of power on most systems.
Basically, from the point of view of a paranoid server security guy trying to deploy a production server, trusted boot makes a certain kind of sense. But I certainly wouldn't want it on my home computer.
Everyone please remember -- this is very important -- that Microsoft is not requiring that x86 mobo/CPU manufacturers lock down their hardware with secure boot. It should be possible to disable secure boot with a simple BIOS switch on x86 hardware. So as long as you aren't running an ARM device built for Windows 8, secure boot won't be a problem for you if you can follow some simple instructions. It's nothing like rooting an Android phone; it's literally just an Enabled/Disabled switch in the BIOS, that's all.
For those who want to run Linux on an upcoming ARM device with enforced Secure Boot, we're basically going to have to break the encryption or find a security vulnerability that allows us to "root" the device. But we have plenty of experience with that from Android and iOS, so I'm sure the community will find ways to do it. This Phoronix post and Matthew's article have absolutely nothing to do with the ARM case, though; that is a whole separate subject.
From the perspective of the x86 market, though, Secure Boot is just another option... it doesn't force you to do anything, it just gives you the ability to do something that may increase the security of your box. And for people who are safeguarding millions or billions of dollars worth of data on a box, that is a material difference to them, and they want it. If you don't, you can still buy that hardware, and disable the option.
The ideal situation would be that the option is enabled by default on products where a majority of users want it, and disabled by default (or not even present) on products where a majority of users don't want it.
So that would lead to a situation like this :
Servers (especially for enterprise use): Users want it; enabled by default; compatible with Linux thanks to signed trusted system (though not custom/proprietary drivers)
x86 Desktops and x86 full-fat laptops: Users don't want it; disabled by default; compatible with Linux because it continues to work as it has with previous-gen hardware
ARM phones and tablets: Many users don't want it but carriers require it because they're assholes; enabled by default; compatible with Linux thanks to signed trusted system (though not custom/proprietary drivers)
ARM Desktops: Do they exist? If they do, I'd hope it'd be disabled by default... but if you ask Microsoft, it'd be enabled just by virtue of the architecture.
Reality is very close to the above, and the main point of contention here is actually with ARM devices that have a cellular baseband and are connected on a cellular network such as 3G or 4G. The main objection(s) that carriers have to allowing uncontrolled code to run on the devices is:
1. Regulatory compliance: they need to retain strict control of what the baseband is doing to keep from violating laws by e.g. the FCC
2. Usage restriction/management: They don't want to let you tether, or if they do, they want to limit you to 5GB tethering plan at an additional fee
3. Bloatware: makes them money if you can't remove apps; developers pay the carrier extra $$$ to have apps installed that you can't remove. You could remove them with full trust e.g. with secure boot disabled.
Bottom line: if you expect to run Linux on a Windows 8 ARM tablet or ARM ultrabook, you're probably going to be disappointed. You MAY be able to get it working with the help of Matthew Garrett's efforts towards Secure Boot with Fedora or RHEL, but it may cost you money and you will definitely be limited as to your choice of software and drivers. If you aren't looking to run Linux on such a device, you can probably disregard this entire discussion.
For me, I will buy x86 desktop and laptop hardware with secure boot, but I will heavily research the product before buying to make sure that the feature is present and functioning properly, to disable it from the BIOS. Because as Alex said, it's possible (though unlikely IMHO) that the BIOS vendor could screw it up and cause the feature to be stuck in the "enabled" position, which would make your device as heavily locked-down as an ARM device.
Last edited by allquixotic; 05-31-2012 at 11:37 PM.
I think that's the real purpose of secure boot and UEFI. Not that there isn't a legitimate case for secure booting but if it prvents you from examining ALL the source code and the firmware then you don't really know who has ultimate control of your pc and data.Barring firmware backdoors
It's like if you send an HTTP request to a remote website without SSL enabled, and a response comes back, you don't know if someone in the middle has messed with the data somehow. You can't verify that it is coming from the endpoint that you sent your request to. But if you send an HTTPS request with SSL or TLS enabled, you are practically guaranteed (barring any vulnerabilities in SSL) that no hosts sitting between you and your endpoint were able to modify the data. If they were, it would immediately fail your message digest check, and your browser would give you a big error message.
This is what secure boot does, but instead of network data, it verifies executable code on disk.
My personal commitment to fight secure boot's unnecessary restrictions on regular users is this: I will never purchase a consumer device (PC, laptop, tablet, smartphone, etc) that has Secure Boot enabled, and cannot be disabled. Those devices can sit on the shelves in the stores, and I will buy devices that let me customize the operating system how I want to.
However, if someone expresses interest in using secure boot in an enterprise context (a server, I mean), I will probably let them know that it can be a good thing, if you know what you're doing. But it does add a lot of unnecessary headache to the configuration/installation of the operating system and software, so we'd have to perform a feasibility investigation to make sure that there are no roadblocks.
Last edited by allquixotic; 05-31-2012 at 11:52 PM.