在 2025/10/22 20:50, Jason Gunthorpe 写道:
On Mon, Oct 13, 2025 at 06:26:11PM +0300, Leon Romanovsky wrote:
From: Leon Romanovsky <[email protected]>
Add support for exporting PCI device MMIO regions through dma-buf,
enabling safe sharing of non-struct page memory with controlled
lifetime management. This allows RDMA and other subsystems to import
dma-buf FDs and build them into memory regions for PCI P2P operations.
The implementation provides a revocable attachment mechanism using
dma-buf move operations. MMIO regions are normally pinned as BARs
don't change physical addresses, but access is revoked when the VFIO
device is closed or a PCI reset is issued. This ensures kernel
self-defense against potentially hostile userspace.
Let's enhance this:
Currently VFIO can take MMIO regions from the device's BAR and map
them into a PFNMAP VMA with special PTEs. This mapping type ensures
the memory cannot be used with things like pin_user_pages(), hmm, and
so on. In practice only the user process CPU and KVM can safely make
use of these VMA. When VFIO shuts down these VMAs are cleaned by
unmap_mapping_range() to prevent any UAF of the MMIO beyond driver
unbind.
However, VFIO type 1 has an insecure behavior where it uses
follow_pfnmap_*() to fish a MMIO PFN out of a VMA and program it back
into the IOMMU. This has a long history of enabling P2P DMA inside
VMs, but has serious lifetime problems by allowing a UAF of the MMIO
after the VFIO driver has been unbound.
Hi, Jason,
Can you elaborate on this more?
From my understanding of the VFIO type 1 implementation:
- When a device is opened through VFIO type 1, it increments the
device->refcount
- During unbind, the driver waits for this refcount to drop to zero via
wait_for_completion(&device->comp)
- This should prevent the unbind() from completing while the device is
still in use
Given this refcount mechanism, I do not figure out how the UAF can
occur.
Thanks.
