On Fri, Mar 19, 2021 at 11:22:21AM -0700, Jacob Pan wrote:

Hi Jason,

On Fri, 19 Mar 2021 10:54:32 -0300, Jason Gunthorpe [off-list ref] wrote:

quoted

On Fri, Mar 19, 2021 at 02:41:32PM +0100, Jean-Philippe Brucker wrote:

quoted

On Fri, Mar 19, 2021 at 09:46:45AM -0300, Jason Gunthorpe wrote:  

quoted

On Fri, Mar 19, 2021 at 10:58:41AM +0100, Jean-Philippe Brucker wrote:
  

quoted

Although there is no use for it at the moment (only two upstream
users and it looks like amdkfd always uses current too), I quite
like the client-server model where the privileged process does
bind() and programs the hardware queue on behalf of the client
process.  

This creates a lot complexity, how do does process A get a secure
reference to B? How does it access the memory in B to setup the HW?  

mm_access() for example, and passing addresses via IPC  

I'd rather the source process establish its own PASID and then pass
the rights to use it to some other process via FD passing than try to
go the other way. There are lots of security questions with something
like mm_access.

Thank you all for the input, it sounds like we are OK to remove mm argument
from iommu_sva_bind_device() and iommu_sva_alloc_pasid() for now?

Let me try to summarize PASID allocation as below:

Interfaces	| Usage	|  Limit	| bind¹ |User visible
/dev/ioasid²	| G-SVA/IOVA	|  cgroup	| No	|Yes
char dev³	| SVA		|  cgroup	| Yes	|No
iommu driver	| default PASID|  no		| No	|No
kernel		| super SVA	| no		| yes   |No

¹ Allocated during SVA bind
² PASIDs allocated via /dev/ioasid are not bound to any mm. But its
  ownership is assigned to the process that does the allocation.

What does "not bound to a mm" mean?

IMHO a use created PASID is either bound to a mm (current) at creation
time, or it will never be bound to a mm and its page table is under
user control via /dev/ioasid.

I thought the whole point of something like a /dev/ioasid was to get
away from each and every device creating its own PASID interface?

It maybe somewhat reasonable that some devices could have some easy
'make a SVA PASID on current' interface built in, but anything more
complicated should use /dev/ioasid, and anything consuming PASID
should also have an API to import and attach a PASID from /dev/ioasid.

Currently, the proposed /dev/ioasid interface does not map individual PASID
with an FD. The FD is at the ioasid_set granularity and bond to the current
mm. We could extend the IOCTLs to cover individual PASID-FD passing case
when use cases arise. Would this work?

Is it a good idea that the FD is per ioasid_set ? What is the set used
for?

Usually kernel interfaces work nicer with a one fd/one object model.

But even if it is a set, you could pass the set between co-operating
processes and the PASID can be created in the correct 'current'. But
there is all kinds of security questsions as soon as you start doing
anything like this - is there really a use case?

Jason
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu