Tainting from user space [LWN.net]

Tainting from user space

Posted May 26, 2006 11:56 UTC (Fri) by kravi (guest, #34351)
In reply to: Tainting from user space by caitlinbestler
Parent article: Tainting from user space

> 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.

(Log in to post comments)

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.