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