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.
Announcement
Collapse
No announcement yet.
UEFI Secure Boot Still A Big Problem For Linux
Collapse
X
-
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.
Leave a comment:
-
Originally posted by Qaridariumyou 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..."
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.
Leave a comment:
-
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 )
Leave a comment:
-
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...
Leave a comment:
-
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.Last edited by Ex-Cyber; 18 January 2012, 12:46 AM.
Leave a comment:
-
Originally posted by Ex-Cyber View PostGarrett'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.
Leave a comment:
-
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.
Leave a comment:
-
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.
Leave a comment:
-
UEFI Secure Boot Still A Big Problem For Linux
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...
Tags: None
Leave a comment: