diff -u: Detainting the Kernel


What's new in kernel development: detainting the kernel.

Note: this post has been updated with a response by Matthew Garrett.

Sometimes someone submits a patch without offering a clear explanation of why the patch would be useful, and when questioned by the developers, the person offers vague or hypothetical explanations. Something like that happened recently when Matthew Garrett submitted a patch to disable a running kernel's ability to detect whether it was running entirely open-source code.

Specifically, he wanted to be able to load unsigned modules at runtime, without the kernel detecting the situation and "tainting" itself. Tainting the kernel doesn't affect its behavior in any significant way, but it is extremely useful to the kernel developers, who typically will refuse to chase bug reports on any kernel that uses closed-source software. Without a fully open-source kernel, there's no way to know that a given bug is inside the open or closed portion of the kernel. For this reason, anyone submitting bug reports to the kernel developers always should make sure to reproduce the bug on an untainted kernel.

Matthew's patch would make it impossible for developers to know whether a kernel had or had not been tainted, and this could result in many wasted hours chasing bugs on kernels that should have been tainted.

So, why did Matthew want this patch in the kernel? It never was made clear. At times he seemed to suggest that the patch was simply a way to avoid having users complain about their kernel being tainted when it shouldn't have been. At one point Ben Hutchings suggested that Matthew might want to allow third parties to sign modules on their own for some reason.

But as no one was able to get real clarity on the reason for the patch, and as tainting the kernel is traditionally a good way to avoid chasing down bugs in closed-source code, none of the developers seemed anxious to accept Matthew's patch.

2018-03-16 — Matthew Garrett responds:

The kernel has the ability to "taint" itself—i.e., to set a flag that tells you something about the kernel state. Most of these flags indicate that something has happened that means the upstream kernel developers are less interested in bug reports in the kernel (because you've loaded a proprietary driver, for instance), but others are more interesting for the local admin.

If a user builds an out of tree module and loads it, the kernel will be tainted with the O flag. If that out of tree module contains proprietary code, the kernel will also be tainted with the P flag. So, loading the nvidia kernel module will cause the kernel to be tainted with both O and P.

If your kernel supports module signatures, then attempting to load an unsigned module will either fail (if the kernel is configured to enforce module signatures) or taint the kernel with the E flag. It's important to note that this isn't a security feature—if you load an unsigned module, then that module is able to modify the kernel to clear the taint flag. The only reason to taint the kernel is to inform the admin that they loaded an unsigned module. Loading the nvidia driver on this kernel would result in the E, O and P taint flags.

Unfortunately some users see the additional E taint and are unhappy, either because they didn't expect it (because it didn't happen with previous kernels) or because they have objections to the kernel wanting them to sign modules. I wrote a patch that allowed distributions to build kernels that could be configured to enforce module signatures, but wouldn't taint if an unsigned module was allowed to load.

With this patch applied and the option enabled, loading the nvidia driver would still result in the O and P flags being set, and upstream kernel developers would still be able to tell that a proprietary driver had been loaded and ask the user to reproduce the bug without that code. However, the kernel would also be usable in cases where you want to require signed drivers.

Distributions and kernel developers don't really care if you've loaded an unsigned module, so the removal of the E taint flag doesn't change anything. But it does mean that distributions can enable support for module signatures without causing confusion for users, which makes it easier for distributions to continue doing development work on new security features that make everyone safer.