| |||||||||||||
Tainting from user spaceTainting from user spacePosted May 25, 2006 18:19 UTC (Thu) by caitlinbestler (guest, #32532)Parent article: Tainting from user space
How does a user mode library obtain access to raw memory
If the kernel has granted such access, it should view
As to the core problem, the Linux kernel realy isn't
(Log in to post comments)
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
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 requiredfor 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
|
|||||||||||||