The return of the lockdown patches

It's been a year since we looked in on the kernel lockdown patches; that's because things have been fairly quiet on that front since there was a loud and discordant dispute about them back then. But Matthew Garrett has been posting new versions over the last two months; it would seem that the changes that have been made might be enough to tamp down the flames and, perhaps, even allow them to be merged into the mainline.

The idea behind kernel lockdown is to supplement secure boot mechanisms to limit the ability of the root user to cause unverified, potentially malicious code to be run. The most obvious way to do that is to use the kexec subsystem to run a new kernel that has not been vetted by the secure boot machinery, but there are lots of other ways that root can circumvent the intent of (some) secure boot users. While the support for UEFI secure boot has been in the kernel for years, providing a way to restrict the root user after that point has always run aground.

A renewed push

The latest round began with a pull request from Garrett at the end of February. He noted that he had taken over shepherding the patch set from David Howells, who is "low on cycles at the moment". There were just a few changes from the previous version that caused the ruckus a year ago.

The main change was to remove the tie-in between secure boot and lockdown mode. The main complaint that Linus Torvalds and Andy Lutomirski had a year ago was about that linkage; they felt that it was unreasonable to force those using secure boot into having a locked-down kernel—and vice versa. At a minimum, kernel developers might well want the flexibility to have one without the other. Changing the fundamental behavior of the kernel based on a BIOS setting that might not be under the control of the user was also seen as highly problematic.

Beyond that big ticket item, there were two other changes. A CONFIG_KERNEL_LOCK_DOWN_FORCE option was added that will build a kernel that always enforces lockdown. Integration with the Integrity Measurement Architecture (IMA) was also dropped, though IMA maintainer Mimi Zohar questioned that plan. There were enough comments that needed addressing to cause Garrett to send a second pull request to security maintainer James Morris in early March.

Zohar was still unhappy with the (lack of) IMA integration, however. Garrett worked on a solution to that, which showed up as a patch in a third pull request on March 25. The patch will use the IMA architecture-specific mechanism to verify a kernel image before allowing it to be booted via kexec:

A patch that disables the use of the bpf() system call in locked-down kernels was also discussed. There are some BPF functions that can read kernel memory, which would allow BPF programs to extract private keys (e.g. the hibernation image signing key) and to alter kernel memory, so the patch simply disabled bpf() entirely. But, given the ever-increasing use of BPF in the kernel, that was seen as a draconian restriction by some. Jordan Glover pointed out that disabling the system call would break some systemd functionality, making locked-down systems less secure.

Disabling BPF was one of the problems that Lutomirski saw with Garrett's approach to decoupling secure boot and lockdown mode. In particular, Lutomirski wanted to see three possible states for lockdown:

The code for disabling direct model-specific register (MSR) writes on x86 systems was also questioned. Writing to MSRs can "lead to execution of arbitrary code in kernel mode", which is why it should be disabled for locked-down kernels. At the behest of Alan Cox, log messages were added to someday facilitate a whitelist of allowed MSR writes, but Thomas Gleixner was not a fan:

Gleixner would much rather see direct access to /dev/msr go away entirely: "The right thing to do is to provide sane interfaces and that's where we are moving to."

Another complaint came from Greg Kroah-Hartman, who said that the heuristic-based patch that restricted debugfs operations for locked-down kernels should instead simply disable debugfs completely. Garrett noted that previous attempts to do so had resulted in "strong pushback from various maintainers", but Kroah-Hartman said he was willing to handle any of those that come along.

Version 31

He got a chance to do just that after Garrett posted version 31 of the patch set. It addressed the complaints, starting with lockdown state:

Beyond that, he removed the logging from the MSR-disabling code and disabled opening files in debugfs when in integrity mode. Perhaps predictably, that latter part led to a complaint. Lutomirski said that reading debugfs files should still be allowed for integrity mode. Kroah-Hartman, who doesn't think much of the lockdown idea in general, said that there are legitimate worries about what kinds of information debugfs provides:

Garrett seems amenable to changing integrity mode to use the previous scheme and to block all reads in confidentiality mode, but doesn't want to "spend another release cycle arguing about it". That previous scheme would only allow opening "safe" debugfs files for read: those with a 00444 mode and lacking .ioctl() and .mmap() methods.

Overall, the comments seem to be fairly minor problems that can be—have been—addressed easily. While some don't buy the whole idea behind lockdown, and there will always be ways around any of its restrictions due to bugs if nothing else, it is something that some kernel users want. Distributions have been shipping with some form of lockdown for quite some time, so it is pretty hard to argue that it is completely useless.

But, of course, the elephant in the room is Torvalds. He has not commented on any of the recent postings. One might guess that most of his concerns were addressed by the decoupling of secure boot and lockdown mode, but that remains to be seen. Morris has not yet said he will merge the lockdown patches either, which would also seem to be a prerequisite. Reducing out-of-tree patches that distributions feel they need to carry is a good goal, though, so one way or another it seems likely that lockdown will get merged before too long.