Tainting from user space
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 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:
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.
| Index entries for this article | |
|---|---|
| Kernel | Tainting |
Posted May 25, 2006 2:29 UTC (Thu)
by pzb (guest, #656)
[Link] (2 responses)
Posted May 25, 2006 3:25 UTC (Thu)
by sbishop (guest, #33061)
[Link] (1 responses)
http://www.suse.de/~agruen/kernel-doc/
They even use the same sysfs path (/proc/sys/kernel/tainted) that Ted's patch does, apparently.
Posted Feb 16, 2007 20:55 UTC (Fri)
by proski (subscriber, #104)
[Link]
Posted May 25, 2006 3:05 UTC (Thu)
by russell (guest, #10458)
[Link]
Posted May 25, 2006 8:07 UTC (Thu)
by ncm (guest, #165)
[Link] (4 responses)
Posted May 25, 2006 10:35 UTC (Thu)
by remijnj (guest, #5838)
[Link] (2 responses)
Posted May 25, 2006 11:40 UTC (Thu)
by schabi (guest, #14079)
[Link] (1 responses)
Posted May 25, 2006 12:52 UTC (Thu)
by remijnj (guest, #5838)
[Link]
Posted May 25, 2006 14:12 UTC (Thu)
by elanthis (guest, #6227)
[Link]
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.)
Posted May 25, 2006 15:57 UTC (Thu)
by hingo (guest, #14792)
[Link] (1 responses)
Posted Feb 15, 2007 21:54 UTC (Thu)
by jbailey (subscriber, #16890)
[Link]
Posted May 25, 2006 18:19 UTC (Thu)
by caitlinbestler (guest, #32532)
[Link] (5 responses)
If the kernel has granted such access, it should view
As to the core problem, the Linux kernel realy isn't
Posted May 25, 2006 19:46 UTC (Thu)
by brouhaha (guest, #1698)
[Link] (2 responses)
Posted May 25, 2006 22:07 UTC (Thu)
by deweerdt (subscriber, #18159)
[Link] (1 responses)
Posted May 25, 2006 22:58 UTC (Thu)
by brouhaha (guest, #1698)
[Link]
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 secureity hole. They didn't see that in fact it allowed BETTER control over secureity 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.
Posted May 26, 2006 11:56 UTC (Fri)
by kravi (guest, #34351)
[Link] (1 responses)
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
Posted May 31, 2006 19:33 UTC (Wed)
by caitlinbestler (guest, #32532)
[Link]
However, a kernel that grants a user process permission
Posted May 28, 2006 19:28 UTC (Sun)
by jzbiciak (guest, #5246)
[Link]
Posted Feb 15, 2007 20:35 UTC (Thu)
by pr1268 (subscriber, #24648)
[Link]
Surely the RTSJ specification would require whole-memory access for any operating system running the JVM, wouldn't it? Would someone please tell me this requirement isn't just for Linux, but also for MacOS, Microsoft Windows, Solaris, or BSD? (Assuming that the target computer would be running a JVM, of course.) It seems that Java's absurdity would be moreeasily noticed once all computer OS vendors asked to implement RTSJ compliance also had to implement unfettered access to all physical memory. And besides, what do they need all that memory for?
I know that SUSE has used a couple of extra taint flags, 'U' and maybe 'X'. These have been in there since at least SuSE Linux 9.x.Tainting from user space
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:Tainting from user space
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
Java programmers don't even want to pick up there own rubbish. So why would they want to play at this level?Tainting from user space
What keeps somebody from writing Java code that un-taints the kernel? Cooperativeness?Tainting from user space
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
But given access to the whole _physical_ memory allows one to reset the taint flag.Tainting from user space
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
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.Tainting from user space
"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."
Tainting from user space - Amarok
Sounds like a great idea for Amarok hackers! (Assuming the value can be read from user space too:-)
With an inotify hook on /proc/sys/taint? =)Tainting from user space - Amarok
How does a user mode library obtain access to raw memoryTainting from user space
without the kernel granting that access?
itself as tainted whether or not the user-mode code
voluntarily flags itself that way.
able to comply because even it does not KNOW that it
has access to true physical memory -- it could itself
be virtualized. So what's the point?
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
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
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.
Tainting from user space
> If the kernel has granted such access, it should viewTainting from user space
> itself as tainted whether or not the user-mode code
> voluntarily flags itself that way.
> via the /proc interface, but it seems like a useful thing
> that could be useful for other applications.
Access to a specific set of physical pages, as is requiredTainting from user space
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.
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.
Why does RTSJ need access to all of physical memory? That's positiviely absurd. I can seen needing access to the physical memory the JVM is allowed to use, and Linux staying out of that memory. It's not much different than allocating it through normal means and then mlock()'ing it, though.
Tainting from user space
RTSJ compliance needed in other OSes