
Why UEFI secure boot is difficult for Linux - mgunes
http://mjg59.dreamwidth.org/9844.html
======
comex
"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.

~~~
mjg59
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.

~~~
lordlicorice
I don't think that makes sense since most Linux users don't even normally have
a C compiler (let alone kernel headers) installed on their systems...

~~~
mjg59
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.

------
keeperofdakeys
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>

------
daeken
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?

~~~
mjg59
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.

~~~
daeken
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.

~~~
mjg59
From a technical perspective, you're absolutely right. From a real world
perspective, it requires a signed kernel and signed drivers.

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

------
lordlicorice
> 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?

~~~
mjg59
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.

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

