On Wed, Sep 29, 2021 at 04:35:19PM +1000, David Gibson wrote: > Yes, exactly. And with a group interface it's obvious it has to > understand it. With the non-group interface, you can get to this > stage in ignorance of groups. It will even work as long as you are > lucky enough only to try with singleton-group devices. Then you try > it with two devices in the one group and doing (3) on device A will > implicitly change the DMA environment of device B. The security model here says this is fine. This idea to put the iommu code in charge of security is quite clean, as I said in the other mail drivers attached to 'struct devices *' tell the iommu layer what they are are doing: iommu_set_device_dma_owner(dev, DMA_OWNER_KERNEL, NULL) iommu_set_device_dma_owner(dev, DMA_OWNER_SHARED, NULL) iommu_set_device_dma_owner(dev, DMA_OWNER_USERSPACE, group_file/iommu_file) And it decides if it is allowed. If device A is allowed to go to userspace then security wise it is deemed fine that B is impacted. That is what we have defined already today. This proposal does not free userpace from having to understand this! The iommu_group sysfs is still there and still must be understood. The *admin* the one responsible to understand the groups, not the applications. The admin has no idea what a group FD is - they should be looking at the sysfs and seeing the iommu_group directories. Jason
