On 2021-11-15 18:19, Christoph Hellwig wrote:
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.
Yup, but as far as I understand we're talking about the situation where
the overall group is already attached to the VFIO domain by virtue of
device A, so any unsolicited DMA by device B could only be to
userspace's own memory.
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?
No idea - I just want to make sure we don't get blinkered on VFIO at
this point and consider the potential problem space fully :)
Robin.
