Torvalds strongly objects to Windows 8 secure boot keys in the Linux kernel
It started innocently enough. Red Hat software engineer David Howells asked Linus Torvalds, Linux's founder, to move on code that would let Microsoft-signed binary keys be added dynamically to a kernel while running in secure-boot mode on the Linux Kernel Mailing List (LKML). Torvalds wasn't having it. "Quite frankly, this is f*cking moronic."
Specifically, Howells was asking "to embed an X.509 certificate containing the key in a section called '.keylist' in an EFI PE [Extensible Firmware Interface Portable Executable] binary and then get the binary signed by Microsoft." Howell was asking for this so that Linux users can add keys with new Linux software in Windows 8 PCs' UEFI Secure Boot prisons. These keys would be needed to help properly boot Linux that needed to use proprietary, binary-only drivers such as some graphic chipsets from AMD and Nvidia.
Like it or lump it, the easiest ways to get Linux installing or running on Windows 8 PCs with Secure Boot all involve using Microsoft signed UEFI keys. Matthew Garrett, a Linux UEFI expert and creator of the shim boot method used by Red Hat, pointed out that these keys are only available from Microsoft as PE binaries.
As anyone who follows Linux closely knows, Linux developers have no love for programs that have no source code and are only available as binaries. It goes against the very grain of open-source software. While most Linux users and programmers will grudgingly use such binaries as proprietary graphic and Wi-Fi drivers, the closer a binary comes to the Linux core, to the kernel itself, the less they like it.
Thus, it shouldn't have come as no surprise when Torvalds blew up.
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 chissake, it's in that f*cking 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.
Garret responded, "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 shi**y firmware is following Microsoft specs. The equivalent isn't just Red Hat (or anyone else) programmatically re-signing those keys, it's re-signing those keys with a key that's trusted by the upstream kernel. Would you be willing to carry a default trusted key if some sucker/upstanding and trustworthy member of society hosted a re-signing service? Or should we just assume that anyone who wants to ship external modules is a f*cking idiot and deserves to be miserable?"
Torvalds fired back, "Quite frankly, I doubt that anybody will ever care, plus getting me to care about some vendor that ships external binary-only modules is going to be hard as hell."
Garrett replied that he can't see Red Hat getting into the key signing business. Peter Jones, a Red Hat software engineer and member of the Fedora Engineering Steering Committee, agreed: " Red Hat will not sign kernel modules built by an outside source. We're simply not going to sign these kernel modules. That's one of the big reasons we want a setup where they can sign their own modules in the first place."
In any case, the real issue, as Garrett sees it, is that "RHEL's [Red Hat Enterprise Linux] is going to end up trusting keys owned by Nvidia and AMD [makers of the most popular graphic chipsets] somehow, and chances are that's going to be based on the Microsoft signing service. The question is whether there's a benefit in ensuring that the same key is trusted by RHEL, Ubuntu, Suse and everyone else or whether different kernels are going to have completely different policies." Hence, Red Hat and Garrett's desire to have a means of dealing with this in the common Linux kernel.
The issue has died down for now, which I take as meaning that Torvalds has won the day. Be that as it may, booting Linux on Windows 8 PCs with Secure Boot active is still a headache -- and dealing with binary drivers will only make it more so.
We can only hope, as Ted Ts'o, a core Linux kernel developer said, that "this whole code signing insanity" … "is completely overblown."
Related Stories: