> From: Jason Gunthorpe <jgg@xxxxxxxxxx> > Sent: Wednesday, April 7, 2021 8:21 PM > > On Wed, Apr 07, 2021 at 02:08:33AM +0000, Tian, Kevin wrote: > > > > Because if you don't then we enter insane world where a PASID is being > > > created under /dev/ioasid but its translation path flows through setup > > > done by VFIO and the whole user API becomes an incomprehensible > mess. > > > > > > How will you even associate the PASID with the other translation?? > > > > PASID is attached to a specific iommu domain (created by VFIO/VDPA), > which > > has GPA->HPA mappings already configured. If we view that mapping as an > > attribute of the iommu domain, it's reasonable to have the userspace- > bound > > pgtable through /dev/ioasid to nest on it. > > A user controlled page table should absolutely not be an attribute of > a hidden kernel object, nor should two parts of the kernel silently > connect to each other via a hidden internal objects like this. > > Security is important - the kind of connection must use some explicit > FD authorization to access shared objects, not be made implicit! > > IMHO this direction is a dead end for this reason. > Could you elaborate what exact security problem is brought with this approach? Isn't ALLOW_PASID the authorization interface for the connection? Based on all your replies now I see what you actually want is generalizing all IOMMU related stuff through /dev/ioasid (sort of /dev/iommu), which requires factoring out the vfio_iommu_type1 into the general part. This is a huge work. Is it really the only practice in Linux that any new feature has to be blocked as long as a refactoring work is identified? Don't people accept any balance between enabling new features and completing refactoring work through a staging approach, as long as we don't introduce an uAPI specifically for the staging purpose? ☹ Thanks Kevin
