Linux devs still scratching heads over the UEFI secure boot

By Darshik Jariwala - February, 27th 2013

The number of people using the Linux distros has grown tremendously over the few years. Compared to few years ago; we see a lot of computer’s running dual-boot OS’s, most commonly Windows with Linux Ubuntu.

Dual-booting your systems used to be fairly easy before, but things changed when Microsoft launched Windows 8 last year. Specifically with the Windows 8 machines that use UEFI firmware with the Secure Boot feature enabled. For someone who only uses windows OS, it isn’t an issue, nothing even to be bothered about for that matter. But for someone who wishes to dual boot his/her system with Linux, it quite complicates the process. It’s not that it is impossible, just more troublesome than before.

 

Be warned of reading Explicit Language

So, a Red Hat developer named David Howells tried to bring this up with Linus Torvalds. Since Linux is open-source, the announcement regarding the development on Linux takes place at the Linux kernel mailing list (LKML), where we also get to the see the debates, discussions and even arguments related to it. David Howells wrote a mail to Linus Torvalds, a part of it reads,

Hi Linus,

Can you pull this patchset please?

It provides a facility by which keys can be added dynamically to a kernel that is running in secure-boot mode. To permit a key to be loaded under such a condition, we require that the new key be signed by a key that we already have (and trust)—where keys that we “already have” could include those embedded in the kernel, those in the UEFI database and those in cryptographic hardware.

Now, “keyctl add” will already handle X.509 certificates that are so signed, but Microsoft’s signing service will only sign runnable EFI PE binaries.

We could require that the user reboot into the BIOS, add the key, and then switch back, but under some circumstances we want to be able to do this whilst the kernel is running.

The way we have come up with to get around this is to embed an X.509 certificate containing the key in a section called “.keylist” in an EFI PE binary and then get the binary signed by Microsoft.

Linus’s reply to the mail, shows us that he isn’t particularly in favor of the it, or even cares. Here’s his response,

Guys, this is not a dick-sucking contest.

If you want to parse PE binaries, go right ahead. If Red Hat wants to deep-throat Microsoft, that’s *your* issue. That has nothing what-so-ever to do with the kernel I maintain. It’s trivial for you guys to have a signing machine that parses the PE binary, verifies the signatures, and signs the resulting keys with your own key. You already wrote the code, for chrissake, it’s in that f**king pull request.

Why should *I* care? Why should the kernel care about some idiotic “we only sign PE binaries” stupidity? We support X.509, which is the standard for signing.

Do this in user land on a trusted machine. There is zero excuse for doing it in the kernel.

Linus

But David Howells thought Torvalds didn’t really get his point and pointed out some problems in idea that Torvalds proposed. He went on to explain further,

There’s a problem with your idea.

(1) Microsoft’s revocation certificates would be based on the hash of the PE binary, not the key.

(2) Re-signing would make the keys then dependent on our master key rather than directly on Microsoft’s. Microsoft’s revocation certificates[*] would then be useless.

(3) The only way Microsoft could then revoke the extra keys would be to revoke our *master* key.

[*] Assuming of course we add support for these.

David

Why is UEFI secure boot a problem for Linux?

UEFI secure boot makes sure that the only codes which are loaded are the ones signed by the signed-trusted authority. Currently, Microsoft is the only company which is recognized and registered as one of those signed-trusted authorities. So now most of the devices that support the UEFI secure boot, comes with the code signed by Microsoft signed–trusted certificate.

Know more about UEFI

Now Microsoft is okay with signing a 3^rd part code. But one of Microsoft’s rules in order for it to sign the code is that, it requires that the code be provided in the format that Microsoft supports. Now Microsoft only supports and signs services running on the PE Binaries. And Linux kernel has it keys signed by their standard X.509 certificates. And what (Linux) it wants to do is, create a master key with their X.509 certificate and embed it within PE binary so it can be bypassed and signed by Microsoft. This will clearly pave the way for Linux OS and as well as the applications within it. Although the developers only wish to do this to create a way to dual-boot their OS with Windows in the UEFI secure boot mode, it also has its disadvantages. In fact, it sort of defeats the purpose of secure boot. If the developers are able to bypass it, it also paves the way to install rootkits and to tamper with the kernel itself. So basically, Linux cannot be booted on a machine with UEFI secure boot unless the bootloader key is signed by Microsoft.

Another Red Hat developer named Matthew Garrett says, “Vendors want to ship keys that have been signed by a trusted party. Right now the only one that fits the bill is Microsoft, because apparently the only thing vendors love more than shitty firmware is following Microsoft specs”.

We can still of course load Linux within Windows (if not alongside it) with Wubi installer, like we always do. It has its disadvantages too though, like stability issues, disk performance is slightly affected (not noticeable to normal user), etc. It’s the best option if you plan to use it for midterm but long term use, maybe not.

In the meantime, it remains to be seen if these Linux developers do achieve what they discussed in the emails because as is visible, Torvalds doesn’t really support the secure boot.

Linus Torvalds is the key person behind the development of Linux Kernel. He acts as project coordinator for now, but when it comes to the development or modification of the kernel, nothing proceeds without his say-so.

Source: arstechnica

Photo Credit – Tobias Sjösten/Flickr