RE: [RFC v2] /dev/iommu uAPI proposal

[Tian, Kevin]

> From: Eric Auger <eric.auger@xxxxxxxxxx>
> Sent: Tuesday, August 10, 2021 3:17 PM
> 
> Hi Kevin,
> 
> On 8/5/21 2:36 AM, Tian, Kevin wrote:
> >> From: Eric Auger <eric.auger@xxxxxxxxxx>
> >> Sent: Wednesday, August 4, 2021 11:59 PM
> >>
> > [...]
> >>> 1.2. Attach Device to I/O address space
> >>> +++++++++++++++++++++++++++++++++++++++
> >>>
> >>> Device attach/bind is initiated through passthrough framework uAPI.
> >>>
> >>> Device attaching is allowed only after a device is successfully bound to
> >>> the IOMMU fd. User should provide a device cookie when binding the
> >>> device through VFIO uAPI. This cookie is used when the user queries
> >>> device capability/format, issues per-device iotlb invalidation and
> >>> receives per-device I/O page fault data via IOMMU fd.
> >>>
> >>> Successful binding puts the device into a security context which isolates
> >>> its DMA from the rest system. VFIO should not allow user to access the
> >> s/from the rest system/from the rest of the system
> >>> device before binding is completed. Similarly, VFIO should prevent the
> >>> user from unbinding the device before user access is withdrawn.
> >> With Intel scalable IOV, I understand you could assign an RID/PASID to
> >> one VM and another one to another VM (which is not the case for ARM).
> Is
> >> it a targetted use case?How would it be handled? Is it related to the
> >> sub-groups evoked hereafter?
> > Not related to sub-group. Each mdev is bound to the IOMMU fd
> respectively
> > with the defPASID which represents the mdev.
> But how does it work in term of security. The device (RID) is bound to
> an IOMMU fd. But then each SID/PASID may be working for a different VM.
> How do you detect this is safe as each SID can work safely for a
> different VM versus the ARM case where it is not possible.

PASID is managed by the parent driver, which knows which PASID to be 
used given a mdev when later attaching it to an IOASID. 

> 
> 1.3 says
> "
> 
> 1)  A successful binding call for the first device in the group creates
>     the security context for the entire group, by:
> "
> What does it mean for above scalable IOV use case?
> 

This is a good question (as Alex raised) which needs more explanation 
in next version:

https://lore.kernel.org/linux-iommu/20210712124150.2bf421d1.alex.williamson@xxxxxxxxxx/

In general we need provide different helpers for binding pdev/mdev/
sw mdev. 1.3 in v2 describes the behavior for pdev via iommu_register_
device(). for mdev a new helper (e.g. iommu_register_device_pasid()) 
is required and then the IOMMU-API will also provide a pasid variation 
for creating security context per pasid. sw mdev will also have its binding 
helper to indicate no routing info required in ioasid attaching.

Thanks
Kevin