Linus Torvalds: I will not change Linux to “deep-throat Microsoft”
"This is not a d**k-sucking contest," says Linux's benevolent overlord.
by Jon Brodkin- Feb 26 2013, 10:09am PST
Linus Torvalds will never get a job in HR.
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:
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.
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.
Warning: Graphic language ahead
Torvalds replied that the idea was "f*cking moronic." Red Hat developer Matthew Garrett noted in response that "There's only one signing authority, and they only sign PE binaries," referring to Microsoft signing Extensible Firmware Interface Portable Executable binaries.
Torvalds' response to Garrett was explicit:
Torvalds' response to Garrett was explicit:
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
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
(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."
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."
PROMOTED COMMENTS
IntergalacticWalrus Ars Scholae Palatinae jump to post
jeamland wrote:
...and RedHat has their own forked version of the kernel already, so why doesn't RedHat just include the relevant changes in their
own kernel?
The whole point of Open Source is that you can make your own changes, right?
...and RedHat has their own forked version of the kernel already, so why doesn't RedHat just include the relevant changes in their
own kernel?
The whole point of Open Source is that you can make your own changes, right?
Yes, but each change you produce that upstream won't merge back means an extra point of deviation for you. For the sake of keeping your fork maintainable it is in your best interest to try and influence upstream to merge back your changes as well. Too much deviation can cause your fork to be impossible to merge back, and therefore be impossible to obtain further enhancements from the upstream without considerable effort.
pavon Ars Scholae Palatinae et Subscriptor jump to post
So here is the situation, if you care more about what is happening than you do about the language people are using to debate it. The point of the patch boils
down to enabling the Linux kernel to trust third-party binary drivers which have been signed by Microsoft. Yes you read that right; Linux drivers signed by
Microsoft.
The purpose of UEFI Secure Boot is to make sure that only code that is signed by a trusted authority can be booted. Nearly all devices that support UEFI Secure Boot will ship with Microsoft's key/cert preloaded, and most will allow you to load other keys/certs, but not all. So to get around this Redhat and others wrote a small shim bootloader signed by Microsoft that will then run anything. This is nice for people who don't care about Secure Boot, and just want to be able to install Linux and have it work without messing with BIOS settings.
However, the vast majority of people who actually want to use Secure Boot in Linux would like for that code signing to extend all the way through the OS. That is UEFI verifies that the bootloader is trusted, the bootloader verifies that the OS is trusted, and the OS verifies that any drivers it loads are trusted. Linux supports this using standard x509 certificates, and all the major distributions sign the binary modules they distribute, so if you add their key as one that is trusted, everything is great.
Except for binary drivers. Redhat doesn't want to sign third-party binary drivers, but they want those drivers to work in this secure boot scenario. And they don't want the users to have to manually add the keys for NVIDIA, AMD, etc (which would the secure thing to do). Instead they had the idea to let third party driver developers submit their drivers to Microsoft to be signed, since the kernel will trust any certificate in UEFI by default anyway and the Microsoft certificate is on nearly all computers. (Edit: Microsoft is cool with this, and does it all the time; as far as they are concerned, they are just verifying the code comes from the specified developer, not that the code isn't malicious)
The complicating factor is that Microsoft will only sign executables in it's own PE format, so they want to enable support in the Linux kernel to load kernel
modules that are wrapped in PE binary format. Linus thinks it is stupid to make a Microsoft certificate the root of your trust to begin with, and thinks it is
even more stupid to add a bunch of code to parse the PE format into the kernel, just to enable this work-around.
down to enabling the Linux kernel to trust third-party binary drivers which have been signed by Microsoft. Yes you read that right; Linux drivers signed by
Microsoft.
The purpose of UEFI Secure Boot is to make sure that only code that is signed by a trusted authority can be booted. Nearly all devices that support UEFI Secure Boot will ship with Microsoft's key/cert preloaded, and most will allow you to load other keys/certs, but not all. So to get around this Redhat and others wrote a small shim bootloader signed by Microsoft that will then run anything. This is nice for people who don't care about Secure Boot, and just want to be able to install Linux and have it work without messing with BIOS settings.
However, the vast majority of people who actually want to use Secure Boot in Linux would like for that code signing to extend all the way through the OS. That is UEFI verifies that the bootloader is trusted, the bootloader verifies that the OS is trusted, and the OS verifies that any drivers it loads are trusted. Linux supports this using standard x509 certificates, and all the major distributions sign the binary modules they distribute, so if you add their key as one that is trusted, everything is great.
Except for binary drivers. Redhat doesn't want to sign third-party binary drivers, but they want those drivers to work in this secure boot scenario. And they don't want the users to have to manually add the keys for NVIDIA, AMD, etc (which would the secure thing to do). Instead they had the idea to let third party driver developers submit their drivers to Microsoft to be signed, since the kernel will trust any certificate in UEFI by default anyway and the Microsoft certificate is on nearly all computers. (Edit: Microsoft is cool with this, and does it all the time; as far as they are concerned, they are just verifying the code comes from the specified developer, not that the code isn't malicious)
The complicating factor is that Microsoft will only sign executables in it's own PE format, so they want to enable support in the Linux kernel to load kernel
modules that are wrapped in PE binary format. Linus thinks it is stupid to make a Microsoft certificate the root of your trust to begin with, and thinks it is
even more stupid to add a bunch of code to parse the PE format into the kernel, just to enable this work-around.
809 posts | registered Nov 17, 2009
Last edited by pavon on Tue Feb 26, 2013 3:21 pm