Re: [PATCH 0/3] uio/dma-buf: Give UIO users access to DMA addresses.

[Jason Gunthorpe <jgg@nvidia.com>]

On Mon, Apr 14, 2025 at 09:21:25PM +0200, Thomas Petazzoni wrote:

> > "UIO is a broken legacy mess, so let's add more broken things
> > to it as broken + broken => still broken, so no harm done", am I
> > getting that right?
> 
> Who says UIO is a "broken legacy mess"? Only you says so. I don't see
> any indication anywhere in the kernel tree suggesting that UIO is
> considered a broken legacy mess.

Explain what the difference is between UIO and VFIO, especially VFIO
no-iommu mode?

I've always understood that UIO is for very simple devices that cannot
do DMA. So it's very simple operating model and simple security work
fine.

IMHO, if the can use DMA it should use VFIO. If you have no iommu then
you should use the VFIO unsafe no-iommu path. It still provides a
solid framework.

As to this series, I have seen a number of requests to improve the
VFIO no-iommu path to allow working with the existing IOAS scheme to
register memory but to allow the kernel the return the no-iommu
DMAable address of the IOAS pinned memory. This would replace the
hacky use of mlock and /proc/XX/pagemap that people use today.

If that were done, could you use VFIO no-iommu?

> Keep in mind that when you're running code as root, you can load a
> kernel module, which can do anything on the system security-wise. So
> letting UIO expose MMIO registers of devices to userspace applications
> running as root is not any worse than that.

That isn't fully true.. UIO isn't fitting into the security model by
allowing DMA capable devices to be exposed without checking for
CAP_SYS_RAW_IO first.

Jason