The Linux kernel development process may welcome all those who love
open source software and have the right coding chops, but one man
remains the ultimate authority on what does and doesn't go into
Linux—and he isn't afraid to let everyone know it.
The rants of Linux creator Linus Torvalds often become public through the Linux Kernel Mailing List archive.
That's the open source way, and it gives us a glimpse into the thinking
of the people behind one of the world's most widely used technologies.
The latest example comes from an argument between Torvalds and other
Linux developers over whether the Linux kernel should include code that
makes it easier to boot Linux on Windows PCs. This goes back to Microsoft requiring
that PCs designed to run Windows 8 use UEFI firmware with the Secure
Boot feature enabled. This has complicated the process of booting Linux
on PCs that shipped with Windows 8, but it hasn't prevented people from
doing so. There are workarounds, but some people are looking for a
solution in the Linux kernel itself.
Last Thursday, Red Hat developer David Howells posed a request to Torvalds, which reads in part:

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.

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*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.
Linus

You might think that would end the conversation for good, but not
quite. Howells pointed out problems in Torvalds' suggested approach, saying:

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

Garrett noted that
modifying the Linux kernel would be due to practicality more than
anything. "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," he wrote.
Greg Kroah-Hartman, maintainer
of the Linux kernel's stable branch and the Linux driver project, put
in his two cents, noting that various Linux distributions already allow
Linux/Windows dual-boot scenarios due to "a UEFI bootloader/shim that
Microsoft has signed." (That shim was created by Garrett.)
"I'm not saying that they are not nice things to have, personally, I
want some of these things for my own machines just to make things more
secure, but again, these are 'I want to have', not 'Someone else is
saying Linux MUST have,'" Kroah-Hartman said.
Howells hasn't given up. In an e-mail yesterday,
he noted that "Unless we get the administrator to add a key prior to
Linux installation, Linux cannot be booted on a secure UEFI
machine—unless the boot loader is signed by Microsoft's key." In the
thread's latest e-mail from today, he responds to one of Kroah-Hartman's arguments.
The discussions illustrate how proposing changes to the Linux kernel
can be controversial. We imagine these types of discussions happen all
the time at software companies, but without becoming public like they do
with Linux. What do the CEOs of major software companies say behind
closed doors when they hate a proposal made by one of their underlings?
We don't know, but when it happens with Linux, we do.
Torvalds isn't a CEO, but the final decision will likely come down to
what he wants. Torvalds is an employee of the Linux Foundation, which
allows him to remain independent while working full-time on maintaining
Linux.
As the Foundation notes, "Torvalds remains the ultimate authority on what new code is incorporated into the standard Linux kernel."