On Mon, Nov 15, 2021 at 05:54:42PM +0000, Robin Murphy wrote: > > s/PIO/MMIO, but yes basically. And not just data trasnfer but > > userspace can interfere with the device state as well. > > Sure, but unexpected changes in device state could happen for any number of > reasons - uncorrected ECC error, surprise removal, etc. - so if that can > affect "kernel integrity" I'm considering it an independent problem. Well, most DMA is triggered by the host requesting it through MMIO. So having access to the BAR can turn many devices into somewhat arbitrary DMA engines. > I can see the argument from that angle, but you can equally look at it > another way and say that a device with kernel ownership is incompatible with > a kernel driver, if userspace can call write() on "/sys/devices/B/resource0" > such that device A's kernel driver DMAs all over it. Maybe that particular > example lands firmly under "just don't do that", but I'd like to figure out > where exactly we should draw the line between "DMA" and "ability to mess > with a device". Userspace writing to the resourceN files with a bound driver is a mive receipe for trouble. Do we really allow this currently?
