Good Lockdown vs. Bad

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

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

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
, 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
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:

Source: Linux Journal