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

Author's Opinion

The views in this column are those of the author and do not necessarily reflect the views of iTWire.

Have your say and comment below.

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."

FREE WHITEPAPER - REMOTE SUPPORT TRENDS FOR 2015

Does your remote support strategy keep you and your CEO awake at night?

Today’s remote support solutions offer much more than just remote control for PCs. Their functional footprint is expanding to include support for more devices and richer analytics for trend analysis and supervisor dashboards.

It is imperative that service executives acquaint themselves with the new features and capabilities being introduced by leading remote support platforms and find ways to leverage the capabilities beyond technical support.

Field services, education services, professional services, and managed services are all increasing adoption of these tools to boost productivity and avoid on-site visits.

Which product is easiest to deploy, has the best maintenance mode capabilities, the best mobile access and custom reporting, dynamic thresholds setting, and enhanced discovery capabilities?

To find out all you need to know about using remote support to improve your bottom line, download this FREE Whitepaper.

DOWNLOAD!

Sam Varghese

website statistics

A professional journalist with decades of experience, Sam for nine years used DOS and then Windows, which led him to start experimenting with GNU/Linux in 1998. Since then he has written widely about the use of both free and open source software, and the people behind the code. His personal blog is titled Irregular Expression.

Connect