On Wed, Apr 07, 2021 at 11:50:02PM +0000, Tian, Kevin wrote:

quoted

From: Jason Gunthorpe <redacted>
Sent: Wednesday, April 7, 2021 8:21 PM

On Wed, Apr 07, 2021 at 02:08:33AM +0000, Tian, Kevin wrote:

quoted

quoted

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.

quoted

quoted

How will you even associate the PASID with the other translation??

PASID is attached to a specific iommu domain (created by VFIO/VDPA),

which

quoted

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

quoted

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?

If the kernel objects don't come out of FDs then no.

Is it really the only practice in Linux that any new feature has to be
blocked as long as a refactoring work is identified? 

The practice is to define uAPIs that make sense and have a good chance
to be supported over a long time period, as the software evolves, not
to hacky hacky a gaint uAPI mess just to get some feature out the
door. 

This proposal as it was oringial shown is exactly the kind of hacky
hacky uapi nobody wants to see. Tunneling an IOMMU uapi through a
whole bunch of other FDs is completely nutz.

Intel should basically be investing most of its time building a robust
and well designed uAPI here, and don't complain that the community is
not doing Intel's job for free.

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? ☹

Since this is all uapi I don't see it as applicable here.

Jason