On Wed, 3 Apr 2019 22:01:14 -0500 Shawn Anastasio <sh...@anastas.io> wrote:
> Hello all, > > I'm currently writing an application that makes use of Qemu's ivshmem > shared memory mechanism, which exposes shared memory regions from the > host via PCI-E BARs. MSI-X interrupts that are tied to host eventfds are > also exposed. > > Since ivshmem doesn't have an in-tree kernel driver, I have been using > VFIO's NOIOMMU mode to interface with the device. This works wonderfully > for both BAR mapping and MSI-X interrupts. Unfortunately though, binding > the ivshmem device to vfio_pci to use it in this way results in a kernel > taint. I understand that this is because without an IOMMU, VFIO/Linux > has no way of preventing devices from performing malicious access to > other system memory. In the case of ivshmem though, the device does not > have any DMA capabilities. The MSI-X interrupt is a DMA. > This has created a situation in which the > safest possible way to access the device (a kernel driver would be > inherently less safe, UIO can't access the MSI-X functionality of the > device) results in a kernel taint, when other, less safe methods don't. MSI-X support in UIO was rejected because MSI-X is a DMA and UIO does not support devices that do DMA. Vfio-noiommu was a compromise to allow using the vfio API, but recognizing that it's inherently unsafe. > In light of this, I propose a change to the VFIO framework that would > allow use cases such as this without a kernel taint. One solution I see > is only tainting when PCI devices with DMA capabilities are bound to > VFIO. It is my understanding that a device's DMA capability can be > determined by checking the Bus Mastering flag in the device's PCI > configuration space, so something like this should be feasible. The bus master bit is not a capability for probing, enabling bus master allows a device to perform DMA, including signaling via MSI interrupts. No bus master, no MSI. > Perhaps an additional NOIOMMU mode could be introduced which only allows > devices which meet this criteria, too (VFIO_NOIOMMU_NODMA_IOMMU?). > Along with a separate Kconfig option, this would allow users to enable > this safe usage at kernel build time, while still preventing the > possibility of an unsafe DMA capable device from being used. > > I'm curious to hear feedback on this. If this is something that can be > merged, I'd be more than happy to write a patch. Add a vIOMMU to your VM configuration (ie. intel-iommu) and use proper vfio in the guest. Thanks, Alex _______________________________________________ vfio-users mailing list vfio-users@redhat.com https://www.redhat.com/mailman/listinfo/vfio-users
