​Matthew Garrett is not forking Linux

But the famed Linux developer is putting his security work into his own Linux tree without Linus Torvalds' approval.
Written by Steven Vaughan-Nichols, Senior Contributing Editor

When Matthew Garrett, well-known Linux kernel developer and ‎CoreOS principal security engineer, announced he was releasing a [Linux] kernel tree with patches that implement a BSD-style securelevel interface, I predicted people would say Garrett was forking Linux. I was right. They have. But, that's not what Garrett is doing.

Matthew Garrett, a prominent Linux developer, is going his own way with Linux code, but he's not forking Linux.
First, Garrett wrote a blog post in response to Intel developer Sarah Sharp leaving the Linux kernel development community. Garrett, like Sharp, has had his own run-ins with Linus Torvalds and others on the Linux Kernel Mailing List (LKML).

In Garrett's case, this conflict sprang from his work with getting Linux boot and install on PCs locked down with Windows 8's UEFI (Unified Extensible Firmware Interface) Secure Boot using a shim approach. This method requires a Microsoft signed UEFI key. Torvalds "hated" the idea. Torvalds snapped, "If Red Hat wants to deep-throat Microsoft, that's *your* issue." Things went downhill from there.

Today, after all the kernel infighting, contemporary major Linux distros -- such as Fedora, openSUSE, Red Hat Enterprise Linux (RHEL), and Ubuntu -- all work on Boot systems with Microsoft-signed "shim" boot loaders.

Garrett today is still bothered that "Linus couldn't be bothered asking questions about the reasoning behind a design before trashing it." So, both because Garrett was "tired of dealing with the crap associated with Linux development" and Linux is, after all, open source and Garrett wants BSD securelevel in Linux, he created in his own Linux kernel tree.

In this codebase, there are currently just BSD-style securelevel interface patches. "Over time it'll pick up some of the power management code I'm still working on," said Garrett, "And we'll see where it goes from there. But, until there's a significant shift in community norms on LKML, I'll only be there when I'm being paid to be there."

So isn't this a fork? In an interview, Garrett said no.

Garrett explained, "I wouldn't say I'm forking. I'd say that I'm doing my own development work away from LKML. Right now it's got the securelevel work in it because that's the only code I have that I feel is ready for public use, but it'll pick up other bits of code that I'm working on as they become mature."

He's building his own kernel tree because "The securelevel feature is part of the work done to make Secure Boot meaningfully useful -- verifying that you're booting a signed kernel isn't terribly useful if it's then straightforward for that kernel to be modified at runtime."

Garrett continued:

"My original patches for this were very tied to Secure Boot, but code's better if the feature is more generalizable. The features it enables (restrictions on module loading, preventing raw access to devices, that kind of thing) are very analogous to those that were used in the BSD securelevel feature, so it made sense to adapt it to a similar interface. That makes it more useful to people who have other verifiable boot setups (e.g, kernels in ROM, dm-verity backed root file-systems, attested measured boot, that kind of thing), who can turn it on after they've done system setup."

This hasn't appeared in the mainline Linux kernel largely because Torvalds dislikes securelevel. As recently as 2013, Garrett tried to get securelevel into Linux but his efforts failed.

So, Garrett said, he found it "necessary to do my own thing. I love doing kernel development. I love making things work. I love solving people's problems. But I don't love LKML or the behavior of various high-profile people within the kernel community, and I realized that I was deliberately avoiding kernel work because I knew that I'd have to deal with LKML afterwards. This is just a way for me to carry on doing something I enjoy doing without having to deal with the bits I don't enjoy. I'm certainly not competing with Linus."

Where does all this lead? Not into a fork, but I believe eventually that Garrett's work will be merged into the main kernel. It seems unlikely to me, however, that Garrett or Sharp will ever be working directly with Torvalds or LKML.

Related Stories:

Editorial standards