There's an ongoing series of skirmishes between corporations who want to sell products that users don't fully control and the kernel developers who want users to be the highest authority. Sometimes these skirmishes manifest in the form of security patches intended to lock down the kernel. Do they lock down the kernel against outside attackers? Or do they lock down the kernel against change from anyone at all, including the user who owns the device?

David Howells recently pushed a patch out of the linux-next, submitting it for inclusion in the main source tree. As he put it, the patch "adds kernel lockdown support for EFI secure boot". And a man page included in the patch said:

The Kernel Lockdown feature is designed to prevent both direct and indirect access to a running kernel image, attempting to protect against unauthorized modification of the kernel image and to prevent access to security and cryptographic data located in kernel memory, whilst still permitting driver modules to be loaded.

The patch gave birth to an odd debate, but a familiar one by now. Matthew Garrett, ultimately the main proponent of the patch, kept defending it on technical grounds that Linus Torvalds felt were meaningless and dishonest, hiding a secret agenda that included helping companies like Microsoft lock users out of making changes to their own systems.

Andy Lutomirski was another critic of Matthew's defense of the patch. The debate circled around and around, with Linus and Andy trying to get Matthew to admit the true motivation they believed he had and Matthew attempting to give solid reasons why the patch should go into the kernel. Things got ugly.

James Morris initially accepted the patch, planning to send it up to Linus for inclusion, and Andy reviewed the code. Among his comments, Andy said the goal of the patch was not clearly stated. He said for the purpose of his code review he would assume the goal was to prevent the root user from either reading kernel memory or intentionally corrupting the kernel.

But, he didn't think those were proper goals for a kernel, even a UEFI Secure Boot kernel. He said, "the kernel should try to get away from the idea that UEFI Secure Boot should imply annoying restrictions. It's really annoying and it's never been clear to me that it has a benefit." He singled out the idea of preventing the root user from accessing kernel memory as one of these annoying restrictions.

Kees Cook replied with his overall justification for this patch. He said: