The UEFI SecureBoot Saga For Linux Continues

[phoronix]

Phoronix: The UEFI SecureBoot Saga For Linux Continues

The UEFI SecureBoot saga for Linux continues with another update by Matthew Garrett of Red Hat...

http://www.phoronix.com/vr.php?view=MTExMTI

[M1kkko]

Interesting news, but.. does this mean Ubuntu will be able to benefit from this as well?

Or will they have to pay another 99 bucks?

[smani]

Interesting news, but.. does this mean Ubuntu will be able to benefit from this as well?

Or will they have to pay another 99 bucks?

They will need to have their own signed first-stage boot loader, if they choose such an approach. Red Hat cannot share the keys it obtained from the signing service, since the whole security of secure boot relies on the private keys being kept secret.

[Kano]

For me that sounds like complete bullshit. If you can sign any bootloader for just 99$ then you don't need secure boot. And when you only use it for a stub loader it is even more fun, because that loader must have got the ability to chainload an efi binary. If you call that binary grub.efi or whatever it does not matter, but what cool checks do you want to implement there? do you want to embed your own key to your chainloader that you verify against your efi bootloader? then you need that key to build your binary, which will be available somewhere, so somehow anybody could use it which access to it. If you can get a signed bootloader for arm why would you enforce it the first time? If you can get it for x86 you could just disable it as well as you gain absolutely nothing. You would not only need to sign binary modules, you would need to sign the initrd - thats the main attack vector against encrypted systems as this is usually stored unencrypted. But as initrds are generated dynamically do you want to sign em then within your own system, well thats also weird...

[crazycheese]

They will need to have their own signed first-stage boot loader, if they choose such an approach. Red Hat cannot share the keys it obtained from the signing service, since the whole security of secure boot relies on the private keys being kept secret.

Of course they can! And of course they will! Which security are you talking about? The best security ever at boot stage has already been invented several decades ago, it was called BIOS MBR protection.All this retarded UEFI "security" is centered around single thing - allow only microsoft to boot, and so cause even more trouble to people who want to try other OSes.

Companies should really stop ass-l1cking microsofties and thing twice what they are doing!

BTW this "happiness" was brought to you by Intel

[Zapitron]

What are Red Hat's customers asking them for?

The first thing is that we'll be disabling the module loading. Right now you can load arbitrary code into grub 2 at runtime, and that defeats the point of secure boot.

Garrett's been saying stuff like this for months, and every time he does, I keep wondering what he's smoking. But maybe it all depends on what the goal is.

Isn't the goal to de-brick EFI machines? You know, so that a Red Hat customer can buy whatever commodity hardware is most ubiquitous, which in tern will refuse to boot unsigned code, and still somehow be able to run Red Hat Linux on it? Isn't that why you're doing this, Garrett?

If so, then nobody gives a damn whether or not loadable modules "defeat the point of secure boot" because the goal of the project is to defeat the point of secure boot, so that computer owners can run whatever code they wish to. And in the case of Red Hat customers, that code is Red Hat's product, hence Red Hat's motivation for doing this. They want to tell customers, "Yes, we have code that you'll be able to run, so give us money."

If that's not the goal -- if the goal is to actually drink the secure boot koolaide, because Red Hat's customers want secure boot, not simply because the hardware they (will be able to) get most easily get requires it, but because those people think it's a good idea to not have final authority on what code their own computers run -- then it all makes sense. But are Red Hat's customers really thinking that way? I don't believe it.

What am I missing?

[agd5f]

secureboot is coming whether you like it or not. You may be able to disable secureboot in the bios, but every bios vendor will implement it differently and some may forget to implement it at all. How do you tell a new Linux user that they have to hit F11 or maybe Delete or maybe F2 during the first few seconds of boot and then wade through a bunch of bios menus to disable a feature called _secure_ boot (let that sink in) just so they can try out this new Linux thing. Kind of a high bar. Realistically you need to support secureboot if you want your OS to be accessible to a wide audience.

[diriel]

Just Ughhh

I am looking into the Coreboot avenue. I believe Google has a couple boards, maybe those can be bought. This honestly just sounds like a mess that I would prefer to avoid. I can see it now, "Hey man my puter wont work, please come fix it ... say 20 minutes ago ok?" /sigh I am the family "IT" guy. Maybe I am just being jumpy.

Can't we all just agree to Say No!?

[johnc]

maybe the UEFI crap will kill the closed source drivers from AMD and nvidia?

i hope the kernel Developers stay hard at this point then the big lose with the name UEFI is a little win for opensource,

We're finally getting Steam and now you want to kill off the high-performance video drivers?

[allquixotic]

We're finally getting Steam and now you want to kill off the high-performance video drivers?

It's not whether anyone wants to or not. It's as Alex said: for systems where disabling secure boot is not an option (because disabling it isn't implemented properly or not at all or the user is too stupid to disable it), it will be impossible to get a signed bootloader / signed kernel for a system with the proprietary modules. That's because the proprietary modules essentially do "user-space modesetting", and most of the real low-level logic is done through a user-space library. Allowing this kind of low-level access into the hardware from userspace would not be permitted by the secure boot folks; they wouldn't allow you to sign a bootloader and kernel that has this kind of gaping security hole, where anyone with root could just write to an arbitrary area in memory.

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.