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]

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

[Qaridarium]

I think its the last time in history for the free world to stand up against Microsoft.

If Microsoft success with this kind of system on the market then the free software world (BSD+Linux+Solaris.....) die.

this is just a nightmare horror...

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

[Qaridarium]

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.

I think this is the plan to make support linux imposible because of the high costs.

You need 1 super linux expert high priced 100 000€ per year per every single linux user to support.

Just because no one can do anything without knowing the "magic key combo" or "open the chassis and close a jumper."

And in the end some people do not understand why they should open the chassis and lose warranty just because Linux is to bad to run out of the box.

imagine the test results in PC magazines : Windows run perfect out of the bux vs linux is a horror nightmare to install you have to open the chassis lose warranty and you need to know a magic key combo and you have to phone to Microsoft to ask for an extra permission key to unlock the Linux install feature ans all this need 10 hours time until you can start to install LINUX!

the test result of the PC magazine is simple: linux is bad linux is worst ......

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

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 )

[Qaridarium]

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 )

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