Home opinion-and-analysis Open Sauce Torvalds blasts Howells, Garrett over secure boot
Torvalds blasts Howells, Garrett over secure boot Featured

A push by Red Hat kernel developer David Howells and ex-Red Hat developer Matthew Garrett to get code supporting secure boot merged into the mainline kernel to meet some of Microsoft's requirements has led to a sharp rebuke from Linux creator Linus Torvalds.

Howell made a request for a patchset to be pulled into the mainline kernel last Thursday, writing, "It (the patchset) 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."

Secure boot is a feature of the Unified Extensible Firmware Interface, the replacement for the BIOS. Microsoft has implemented secure boot on all hardware that is pre-installed with Windows 8, hence anyone looking to boot an image on such hardware would need to obtain a key from Microsoft.

Garrett has developed a first-stage bootloader to facilitate the process of Linux distributions booting on a device which has secure boot enabled. The Linux Foundation's James Bottomley has also developed a first-stage bootloader.

Booting is, however, just the first step for Linux systems that wish to keep running on hardware that is secure boot-enabled. Beyond merely booting, a Linux system also needs to be able to handle hibernation properly so that the image that returns from hibernation is trusted. This happens with Windows 8, and not with Linux.

Further, the kexec system call also poses issues as it can replace the running kernel with a different program. This could breach the secure boot trust model. These two issues have to be sorted out to meet Microsoft's requirements, else the keys issued to distributions by the Microsoft-assigned key-vendor could well be withdrawn.

In his response to Howells, Torvalds was caustic, writing: "Not without a lot more discussion first. Quite frankly, this is f**king moronic. The whole thing seems to be designed around stupid interfaces, for completely moronic reasons. Why should we do this? I already dislike our existing X.509 parser. And this makes the idiotic complicated interfaces, and now it goes up to 11."

Microsoft's signing service will sign only runnable EFI portable executable binaries. The kernel already has a way of handling X-509 certificates that are signed.

To get around this, Howells wrote, "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."

Garrett then piped up in support, saying, "There's only one signing authority, and they only sign PE binaries."

Torvalds went ballistic. "Guys, this is not a d**k-sucking contest," he wrote. "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 (sic), 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."

Garrett responded: "There's one significant practical awkwardness, which is that it makes key revocation a multi-step process - the blacklisted hash is going to be for the PE and not the key itself. I guess the original hash could be stuffed in some metadata in the key, but urgh.

"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. 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**king idiot and deserves to be miserable?

"(I mean, *I'm* fine with the idea that they're f**king idiots and deserve to be miserable, but apparently there's people who think this is a vital part of a business model)."

Torvalds was unconvinced. "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," he wrote. "Plus quite frankly, signing random kernel vendor modules (indirectly) with a MS key is f**king stupid to begin with.

"In other words, I really don't see why we should bend over backwards, when there really is no reason to. It's adding stupid code to the kernel only to encourage stupidities in other people.

"Seriously, if somebody wants to make a binary module for Fedora 18 or whatever, they should go to Red Hat and ask whether RH is willing to sign their key. And the whole 'no, we only think it makes sense to trust MS keys' argument is so f**king stupid that if somebody really brings that up, I can only throw my hands up and say 'whatever'.

"In other words, none of this makes me think that we should do stupid things just to perpetuate the stupidity. And I don't believe in the argument to begin with."


With 50+ Speakers, 300+ senior data and analytics executives, over 3 exciting days you will indulge in all things data and analytics before leaving with strategic takeaways that will catapult you ahead on your journey

· CDAO Sydney is designed to bring together senior executives in data and analytics from progressive organisations
· Improve operations and services
· Future proof your organisation in this rapidly changing technological landscape
· CDAO Sydney 2-4 April 2019
· Don’t miss out! Register Today!
· Want to find out more? Download the Agenda



Australia is a cyber espionage hot spot.

As we automate, script and move to the cloud, more and more businesses are reliant on infrastructure that has the high potential to be exposed to risk.

It only takes one awry email to expose an accounts’ payable process, and for cyber attackers to cost a business thousands of dollars.

In the free white paper ‘6 Steps to Improve your Business Cyber Security’ you’ll learn some simple steps you should be taking to prevent devastating and malicious cyber attacks from destroying your business.

Cyber security can no longer be ignored, in this white paper you’ll learn:

· How does business security get breached?
· What can it cost to get it wrong?
· 6 actionable tips


Sam Varghese

website statistics

Sam Varghese has been writing for iTWire since 2006, a year after the sitecame into existence. For nearly a decade thereafter, he wrote mostly about free and open source software, based on his own use of this genre of software. Since May 2016, he has been writing across many areas of technology. He has been a journalist for nearly 40 years in India (Indian Express and Deccan Herald), the UAE (Khaleej Times) and Australia (Daily Commercial News (now defunct) and The Age). His personal blog is titled Irregular Expression.


Popular News




Sponsored News