UEFI Secure Boot Still A Big Problem For Linux

[phoronix]

Phoronix: UEFI Secure Boot Still A Big Problem For Linux

Matthew Garrett has provided some insight regarding some of the problems still outstanding for Linux to handle UEFI Secure Boot...

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

[gigaplex]

Verification of kernel modules necessary?

I was under the impression that UEFI Secure Boot just placed requirements on the bootloader to be signed. It's up to the bootloader whether it wants to trust the kernel, and up to the kernel whether it wants to trust the kernel modules. Surely it would be possible to just sign the bootloader to make Linux work with UEFI Secure Boot, with the caveat that it's not really taking advantage of the underlying purpose of Secure Boot.

[Ex-Cyber]

Garrett's point is not that the UEFI spec requires it, it's that no such key can be allowed by default without subverting the entire system, because then malware can just use the "trusted" Linux components to chainload itself. Hence systems with Secure Boot enabled will require the user to install a key in order to install an unrestricted OS, and there is no standard procedure/interface/format for installing a key, which creates a support nightmare.

Think of getting CACert trusted in your browser, but instead of a different procedure for each web browser there's a different procedure for each motherboard/system vendor, you can't follow along with the instructions in another browser tab/window (because your system's not booted yet), and you have to redo it every time you want to switch distros. Hardcore enthusiasts who can memorize a few screenfuls of memory/bus timing and voltage settings might have no problem with this. Anyone resembling a regular user/admin will probably find it to be at least annoying, and that's making the optimistic assumption that vendors don't ship it in a horribly untested/broken state.

[gigaplex]

Garrett's point is not that the UEFI spec requires it, it's that no such key can be allowed by default without subverting the entire system, because then malware can just use the "trusted" Linux components to chainload itself. Hence systems with Secure Boot enabled will require the user to install a key in order to install an unrestricted OS, and there is no standard procedure/interface/format for installing a key, which creates a support nightmare.

Think of getting CACert trusted in your browser, but instead of a different procedure for each web browser there's a different procedure for each motherboard/system vendor, you can't follow along with the instructions in another browser tab/window (because your system's not booted yet), and you have to redo it every time you want to switch distros. Hardcore enthusiasts who can memorize a few screenfuls of memory/bus timing and voltage settings might have no problem with this. Anyone resembling a regular user/admin will probably find it to be at least annoying, and that's making the optimistic assumption that vendors don't ship it in a horribly untested/broken state.

I largely agree with what you say, however even if Linux could properly support Secure Boot (with respect to signed kernel modules) the problem of requiring installation of a key is going to be an outstanding issue anyway. No OEM is going to add a global Linux key to their firmware by default (unless Linux just happens to be preinstalled, which is very rare - it would most likely have to be a distro specific key though).

[Ex-Cyber]

Yeah; the point is that if this were properly specified, the BIOS could just automatically pop up a slightly scary UAC-like "Do you really want to install a new OS from this device?" prompt, the user could click "Yes" (and enter the BIOS config password if such is configured), and that would be the end of it. As it is, it could be anything from an obscurely documented magic key combo to requiring the user to crack open the chassis and close a jumper.

[Kano]

On x86 systems that secure boot problem should not really exist as you can disable it. If they want they could ship prebuild signed vbox modules, thats absolutely no problem. For nvidia/fglrx you could too when you see it a bit more releaxed. But i highly doubt that this will make linux installs more secure, simply because there are much simpler attacks possible that do not require changeing a kernel module. Lets think about the initrd, which is also stored on an unencrypted place usually. If the initrd needs to be signed as well then you really get into trouble as you can not recreate it anymore which is always done when you enable/disable binary drivers, whenever you add/remove extra components like for live mode and whatever. To build really secure systems the only way i could think of is using hd integrated encryption in order to prevent changes to unsecured boot parts. Even if you use a bios pw (and no hd pw) and let a laptop stay alone unprotected an attacker could remove the disk, modify the initrd and put it back. you can do everything in the initrd that you want to do, you can even run the whole linux system from an initrd alone. So securing that would be really a good idea if you have got confidential data on your system. Do not think that partial hd encryption solves any issues that somebody with hardware access can not solve. keyloggers in keyboards or whatver are also possible. So lets go back to secure boot. I can definitely understand that there is a purpose to force it for some specific devices in order to prevent attacks. If you could disable it, then it would be not so efficent. Needless to say that nobody is forced to buy a W8 arm system when Linux should run on it, there might be already even cheaper devices with Linux preinstalled on it...

[staalmannen]

Virtualization to the rescue? Or user-space drivers?

Perhaps the easiest way to support all open source operating systems (not only the major Linux distributions that can afford the effort of getting signed kernels) would be a standardized virtualization layer that would be signed.

As that virtualized layer has loaded, you could run stuff the same way that you do now without worrying about the "secure boot". With some effort it may even give some security advantages similar to those claimed by microkernels.


An alternative would be to have a user space interface for drivers (so a linux driver would either be compiled in, a loadabe module or completely in userspace), with the added advantage that drivers could be portable between operating systems (I for one would think that it would be a good thing if other operating systems could run linux drivers )

[staalmannen]

you sound like: "oh yes microsoft hurt me i like it its a feature for me i make the best ever out of it give me more of it oo yeess..."

I don't care one sh*t about MS (either way - I just don't care) and I have not had anything to do with them for many years. Thanks to Linux I run relatively old computers so the UEFI will not hit me in a long while. The secure boot feature is however something that also lots of Linux people actually want Fundamentally, it is a good technology - with the huge bug that it can be abused by the dominant player (MS) and its control over the OEMs. Personally I think that regulators (EU, US etc) need to keep an eye on this technology shift and make sure that installing optional operating systems are easy on all OEM machines sold (including ARM ones).

For the major distros, they can probably go for signed kernels and run on bare hardware, but for the hobbyist or someone running a less usual distro or alternative open source OS (*BSD, illumos, Plan9 ...), an alternative solution would have to be found - for example a signed microkernel handing over control to the guest OS as soon as possible.

[kobblestown]

From article: "Signed Linux kernels must refuse to load any unsigned kernel modules."

Why? Secure Boot requires a signed kernel (or isn't it, rather, a signed boot loader?) but the kernel can do anything after boot. Yes, it defies the idea that you should only run trusted code but that can be a boot option or, as someone wrote above, the out of tree projects can provide signed modules.

[Drago]

I really this whole sh*t will boost coreboot development. And after all, one of the motherboard companies will make coreboot at least an option. I am eager to hear about the first laptop with coreboot support on FOSDEM after 2 weeks.

http://fosdem.org/2012/schedule/event/coreboot_laptops