Re: [PATCH v5 9/9] vfio/pci: Add dma-buf export support for MMIO regions

Shuai Xue
2025-10-28T13:46:57Z

在 2025/10/27 20:09, Jason Gunthorpe 写道:
> On Sun, Oct 26, 2025 at 03:55:04PM +0800, Shuai Xue wrote:
>>
>>
>> 在 2025/10/22 20:50, Jason Gunthorpe 写道:
>>> On Mon, Oct 13, 2025 at 06:26:11PM +0300, Leon Romanovsky wrote:
>>>> From: Leon Romanovsky <leonro@nvidia.com>
>>>>
>>>> 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.
>
> A second vfio device can be opened and then use follow_pfnmap_*() to
> read the first vfio device's PTEs. There is no relationship betweent
> the first and second VFIO devices, so once the first is unbound it
> sails through the device->comp while the second device retains the PFN
> in its type1 iommu_domain.
>
> Jason

I see.

Thanks.

Best Regard,
Shuai