There's absolutely no technical reason that a signed bootloader would have to only boot signed kernels. With UEFI Secure Boot, the only signed component is the bootloader -- there's absolutely no way in which this can affect the kernel. Now, it's possible that there could be procedural mandates around this, e.g. an authority that signs your bootloader and won't do so without mandating that the kernel and all drivers be signed as well, but does this exist, or will it exist?
It'd be easy to generate a signed bootloader that runs unsigned kernels. It'd also be easy to then use that bootloader to boot malware to attack Windows. For secure boot to be in any way useful it would then be necessary to blacklist that signed bootloader. Signed kernels that load unsigned drivers have the same problem.
I'm not arguing that Secure Boot is useful or good in any way, I'm simply saying that from a technical perspective, signed bootloader does not mean signed kernel.
Hardware encryption should mitigate that issue, just so unsigned kernels aren't allowed access to the keys (which would prevent you from running hardware encryption with an unsigned kernel, but that's sensible.)
The keys aren't an issue. The issue is whether you can run untrusted ring 0 code before running another OS, because if you can then you can subvert the trust model.
A computer that boots code that loads un-signed modules isn't secure at all. I suspect that will be the outcome of UEFI: no effective increase in security, and hassles installing new operating systems.
Frankly, I have no interest in my computer being secure in this way (running only code signed by companies). UEFI might have a place in kiosks or shared computers in public libraries, but not for a computer I own and physically control.
Adding a key may involve typing in hundreds of hex digits to a BIOS screen, with typical BIOS user interface. That will be a barrier to switching to Linux.
The authority exists, the manufactures. The whole purpose of secure boot is to stop untrusted code running. If something the manufactures sign can run third party code, then it can be used to run untrusted code. This means they will either never make such a key, or revoke it when they do sign it. This simply means, with its current design, linux is incompatible with secure boot.
"Signing the kernel isn't enough. Signed Linux kernels must refuse to load any unsigned kernel modules. Virtualbox on Linux? Dead. Nvidia binary driver on Linux? Dead. All out of tree kernel modules? Utterly, utterly dead. Building an updated driver locally? Not going to happen. That's going to make some people fairly unhappy."
Making secure boot meaningful on Linux would be a big project - you'd also have to sign most of the stuff in userland. But if it were done, it would be done by the distro, which could easily enough sign the kernel module in its VirtualBox package and whatever else users might want to load into the kernel. Since this would presumably be optional (there would be an alternate signed bootloader that loaded an unsigned kernel for developers and power users), the GPL3 would be satisfied; and the end result is a system that's significantly harder to attack. I don't know if that's worth the effort, considering the lack of actual malware for Linux, but as long as the key is installed along with the OS, it's hardly an impossibility.
If you provide binary Virtualbox drivers, sure. I'm not aware of any distributions that do that - they provide source instead. And signing external drivers requires auditing them to make sure that there's no way they can be exploited to execute arbitrary code, because if they can then you've just signed a malware loader and Microsoft (if they're serious about secure boot being about security) blacklist your key.
Most Linux users don't normally use any out of tree drivers. https://help.ubuntu.com/community/VirtualBox/Installation indicates that Virtualbox is shipping via DKMS, which is infrastructure for automatically rebuilding the Virtualbox code every time the kernel is updated.
The author of this blog also gave a talk about his work implementing UEFI in linux, and the issues discussed in this post, at a conference in Australia. I strongly suggest watching this talk when the videos are released. http://linux.conf.au/schedule/63/view_talk?day=tuesday
> GPLv3 has various requirements for signing keys to be available. Microsoft's new requirement that systems support the installation of user keys would let users boot their own modified bootloaders, so that may end up being sufficient to satisfy the license.
I don't understand. What does Microsoft have to do with GPLv3 requirements?
If it's possible for the user to use their own key then GPLv3 may permit you to ship signed code without the signing key - the user will just be able to sign modified versions themselves. Microsoft's current requirements include the ability for users to install their own keys.
This idea of requiring everything to be signed from the bootloader up (or just the bootloader) is horrifying to me. It seems just as bad or worse than SOPA and the rest of it.
Can the BIOS be reverse-engineered to hack out the UEFI code, sort of similar to how crackers just NOP the DRM part a game? You could even return the correct response to any kernel interrogation of the BIOS to check keys.
Seems to me that solves most of the problem, even for dual-booters.
20 comments
[ 2.6 ms ] story [ 50.6 ms ] threadFrankly, I have no interest in my computer being secure in this way (running only code signed by companies). UEFI might have a place in kiosks or shared computers in public libraries, but not for a computer I own and physically control.
A way to add/remove signing keys is necessary (think NSAKEY).
Making secure boot meaningful on Linux would be a big project - you'd also have to sign most of the stuff in userland. But if it were done, it would be done by the distro, which could easily enough sign the kernel module in its VirtualBox package and whatever else users might want to load into the kernel. Since this would presumably be optional (there would be an alternate signed bootloader that loaded an unsigned kernel for developers and power users), the GPL3 would be satisfied; and the end result is a system that's significantly harder to attack. I don't know if that's worth the effort, considering the lack of actual malware for Linux, but as long as the key is installed along with the OS, it's hardly an impossibility.
I don't understand. What does Microsoft have to do with GPLv3 requirements?
Seems to me that solves most of the problem, even for dual-booters.