Tainting from user space [LWN.net]

The kernel has long used "tainting" as a way of noting that something has happened which may affect the stability of the system. Should a kernel oops occur, the resulting kernel trace includes information on the kernel's taint status. This information can then be used by developers to ask hard questions about what was really going on. The taint flag was originally added to flag the use of binary-only kernel modules, but its use has grown since then. Events which will taint a current kernel include the forced removal of a module, loading a module without proper (or matching) version information, or running an SMP kernel with processors not designed for SMP operation. Machine check exceptions and certain kinds of memory management errors will also result in a tainted kernel.

A recent patch by Ted Ts'o expands the taint concept in an interesting way. It adds a new file (/proc/sys/kernel/tainted); should user space write to that file, the kernel will be marked tainted with the new "U" flag. The idea, says Ted, is to flag "when userspace is potentially doing something naughty that might compromise the kernel." It took a few more questions before the real truth of the matter came out:

The problem is that the Real-Time Specification for Java (RTSJ) **requires** that the JVM provide class functions which provide direct access to physical memory; all physical memory. In fact, the RTSJ compliance test explicitly checks for this; it requires that you give the compliance test the address of a few hundred megs of physical memory for the test. The absolutely hilarious bit about all of this is that the same customer who wants RTSJ compliance because of federal procurement regulations is also interested in using SELinux.

The idea of using SELinux on a system where Java code is free to mess around with physical memory does involve a fair amount of cognitive dissonance. But The Customer Is Always Right, so Ted is making this work. Not entirely willingly, though:

In fact, I was so unhappy about being forced by the RTSJ specification to do this insane thing that I wanted to make sure that if it were ever used, it would set a TAINT flag to warn people that just about anything unsane could have happened, and the system's stability was at the mercy of the competence of Java application programmers.

Nobody has stepped forward to say that the kernel should not be tainted in such a situation. Instead, one might almost be able to merge a patch causing the kernel to emit scary horror-movie sounds as well.

There appears to be general agreement that this patch makes sense; certainly there are plenty of situations where user-space actions might affect the stability of the system. There was one request for a log message to be stored with the user-space taint flag so that the reason for its presence would be more clear later on. A concern was also raised that some distributions were using the "U" flag for other reasons (to flag the presence of "unsupported" modules), though it is not clear that this is actually happening. Collisions over the use of taint flags could indeed create confusion, so Dave Jones has suggested that any taint flags used in out-of-tree code should at least be documented with a comment in the mainline kernel. Whether any such flags exist remains to be seen, however.

(Log in to post comments)

Tainting from user space

Posted May 25, 2006 3:25 UTC (Thu) by sbishop (guest, #33061) [Link]

Yes, I've seen this. Loading a (GPLed) kernel module, that I'd written, on a SUSE 9.3 box produced a "kernel tainted" message in the system logs, which confused me at first. If you Google for this, you'll see that this is a bit of a FAQ. Here's a link to the SUSE docs which describe the different flags:

http://www.suse.de/~agruen/kernel-doc/

They even use the same sysfs path (/proc/sys/kernel/tainted) that Ted's patch does, apparently.

Tainting from user space

Posted Feb 16, 2007 20:55 UTC (Fri) by proski (subscriber, #104) [Link]

That would be a taint flag indicating that although you are using free software, Microsoft didn't promise not to sue you over patents. That's a taint flag some people would display proudly :)

Tainting from user space

Posted May 25, 2006 10:35 UTC (Thu) by remijnj (guest, #5838) [Link]

I think tainting is a one-way street and that a kernel can't be untainted. The article doesn't mention that writing '0' to the sysfs file untaints it.

Tainting from user space

Posted May 25, 2006 11:40 UTC (Thu) by schabi (subscriber, #14079) [Link]

But given access to the whole _physical_ memory allows one to reset the taint flag.

Tainting from user space

Posted May 25, 2006 12:52 UTC (Thu) by remijnj (guest, #5838) [Link]

Hmmm, didn't think of that. You are ofcourse correct. If a user space process has access to physical memory all bets are off.

Tainting from user space

Posted May 25, 2006 14:12 UTC (Thu) by elanthis (guest, #6227) [Link]

What would be the purpose of doing this, though? The only thing it would allow is wasting a little kernel developer time when a bug report is submitted. Whoopee.

Second, setting that flag by poking around memory probably isn't that easy. Where in memory is the flag, exactly? With how every kernel release (and almost every kernel compilation) can end up with pretty drastically different memory layouts, it's not possible to just write some data to some specific memory location. You would have to write an awful lot of very complex code just to figure out where to write the change. And if the code isn't absolutely right, you probably just end up crashing the machine. (And, hence, if you do a bug report of the oops message, it shows developers the kernel was tainted.)

Tainting from user space - Amarok

Posted Feb 15, 2007 21:54 UTC (Thu) by jbailey (subscriber, #16890) [Link]

With an inotify hook on /proc/sys/taint? =)

Tainting from user space

Posted May 25, 2006 19:46 UTC (Thu) by brouhaha (subscriber, #1698) [Link]

Exactly the same point I was going to make. On the rare occasions when I've accessed physical memory from user space, I've done it by mmap()ing /dev/mem. Arguably any user process that mmap()s /dev/mem or /dev/kmem with write permission should result in a tainted flag, without any explicit request for that flag by the user process.

Tainting from user space

Posted May 25, 2006 22:07 UTC (Thu) by deweerdt (subscriber, #18159) [Link]

Except that mmaping /dev/mem with r/w permissions is exactly what every X process does... So a lot of kernels out there would be "tainted" in a way.

Tainting from user space

Posted May 25, 2006 22:58 UTC (Thu) by brouhaha (subscriber, #1698) [Link]

That's what I thought too, and certainly it's how it used to be done, but by now if it hasn't moved to mmap()ing a specific PCI region file, it certainly should.

Back around 1999 I proposed that /proc/pci should have mmap()able files for each PCI memory region configured for a device. It looks like by 2003 this had been implemented, based on a post by David Miller to the LKML on 24-oct-2003.

When I proposed that idea, it met a lot of resistance from people that thought it would somehow open a security hole. They didn't see that in fact it allowed BETTER control over security by using filesystem permissions to restrict an X server to only accessing the video card, and not being able to scribble over arbitrary memory. These days, with udev, it should even be possible to make the video card PCI regions owned by a specific user (e.g., "xserver"), and not give the X server root permissions at all.

Tainting from user space

Posted May 26, 2006 11:56 UTC (Fri) by kravi (guest, #34351) [Link]

> If the kernel has granted such access, it should view
> itself as tainted whether or not the user-mode code
> voluntarily flags itself that way.

The kernel doesn't necessarily know that some module is allowing user-space access to physical memory. A module can allocate whatever number of physical pages it wants and allow it to be mmap()ed using a pseudo-device. (BTW, this is what the rmem module in Ted's patch is doing). So it is upto the module to decide whether such access taints the kernel or not.

I think drivers like open-ib (Infiniband) and open-rdma have a legitimate need for such access. So such drivers would not want to taint the kernel.

Note that the patch taints the kernel from within the module. The /proc file is only an additional feature. To quote Ted:

> Technically speaking, we don't need to be able to set it
> via the /proc interface, but it seems like a useful thing
> that could be useful for other applications.

Tainting from user space

Posted May 31, 2006 19:33 UTC (Wed) by caitlinbestler (guest, #32532) [Link]

Access to a specific set of physical pages, as is required
for RDMA and graphics cards, is not what I would call "raw
access". It is resource allocation. The fact that a user
can damage a resource that has been allocated to it does
not make the kernel itself suspect.

However, a kernel that grants a user process permission
to write to *any* memory (including the kernel) doesn't
have much of a leg to stand on in making distinctions
between "tainted" code and "non-tainted" code. As soon
as the permission to update the memory where the kernel's
code is stored is granted to a user process, that user
process effectively becomes part of the kernel.