The UEFI SecureBoot Saga For Linux Continues

[Qaridarium]

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.

will it be possible to just flash a coreboot with flashrom over the BAD and EVIL UEFI ?

[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.

[Qaridarium]

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

for me closed source is not a highend feature its more a tool to make sure sure you can not improve your old hardware to escape from the planed obsolescence

[Qaridarium]

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.

in your world professionals only use UEFI ? i think REAL Professionals use coreboot in the bios flash rom and a hardware jumper to set the boot rom to read only

LOL !!! tell me how do a hacker BEAT this security solution ?

[linux5850]

Barring firmware backdoors

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.

[allquixotic]

will it be possible to just flash a coreboot with flashrom over the BAD and EVIL UEFI ?

Being able to flash would require a permission that would probably not be granted with Secure Boot enabled. The short answer is, no, you would not be able to overwrite the BIOS with something else unless you already disabled Secure Boot, which would then defeat most of the purpose of flashing the BIOS in the first place. I think you wanted to flash CoreBoot over top of UEFI while Secure Boot is ENABLED and I think this will either be 100.0% impossible, or will require "hacking" (hardware hacking or exploiting a security vulnerability).

[linux5850]

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.

I don't think it's just a BIOS thing. I think it's also a TPM chip built into your pc that's does the checking for keys and allowing which code can boot or not.

[allquixotic]

in your world professionals only use UEFI ? i think REAL Professionals use coreboot in the bios flash rom and a hardware jumper to set the boot rom to read only

LOL !!! tell me how do a hacker BEAT this security solution ?

That sounds pretty secure indeed, but requires toggling a switch on the motherboard each time you want to change any files in the operating system. Also, this method does not provide any way to verify that all of the binaries present on the system are genuine: if they were somehow modified through an exploit of some kind, you wouldn't be able to know.

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.

[Qaridarium]

Being able to flash would require a permission that would probably not be granted with Secure Boot enabled. The short answer is, no, you would not be able to overwrite the BIOS with something else unless you already disabled Secure Boot, which would then defeat most of the purpose of flashing the BIOS in the first place. I think you wanted to flash CoreBoot over top of UEFI while Secure Boot is ENABLED and I think this will either be 100.0% impossible, or will require "hacking" (hardware hacking or exploiting a security vulnerability).

i mean something like this: flashing coreboot on a bios chip and then replace the bios chip

maybe this is the first act for linux users in the future.

and explain to me why is a hardware jumper to set the bios flash to read only not a better solution than UEFI ?