Hi Jason,

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

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.
³ Include uacce, other private device driver char dev such as idxd

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?

Thanks,

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