Messages in this thread | | | Date | Mon, 15 Nov 2021 18:44:27 +0000 | Subject | Re: [PATCH 03/11] PCI: pci_stub: Suppress kernel DMA ownership auto-claiming | From | Robin Murphy <> |
| |
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.
| |