[vfio-users] Avoiding VFIO NOIOMMU taint in safe situations

[Alex Williamson]

On Wed, 3 Apr 2019 22:01:14 -0500
Shawn Anastasio <shawn at 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