[Qualcomm feedback] 7.3.2. IDE Link - flow

[jyao1]

Reference: https://lists.riscv.org/g/tech-ap-tee-io/topic/103498833#47

The IDE link initial setup must go through the following steps:

It is not stated that IOMMU-MTT must also be enforced for any given SDID/TSM (prerequisite).
How/when should RDSM update IOMMU-MTT PTEs for a given trusted device?

[sameo]

@ravi Do you confirm that RDSM should intercept the CoVE-IO connection and binding SBI calls to program the IO-MTT?

[rsahita]

we should specifically describe the role of the RDSM w.r.t the IOMTT programming - this may need a seperate interface instead of saying that the RDSM intercepts?

So, COVH is the interface between the host and the TSM and covers the interaction of binding a TDI which is under the purview of a RP/IOMMU to a TVM. In that sense, COVH assumes a 1:1 interaction between the hosting domain and the confidential domain TSM.

The RDSM OTOH owns programming of the MTT to enforces sup. dom. isolation and that the IOMMUs memory-mapped programming regions are access-restricted to the sup. dom. the IOMMU has been assigned to. So the IOMMU un/assignment ABI should really be serviced by the RDSM. The second interface the RDSM must support is the programming of the SDCL - which maps an IO request to the SDID and IOMMU ID - so this ABI to program the IOMTT is also to be serviced by the RDSM. Through this second ABI function, the RDSM will enforce consistency of the Deviceid/IDE Stream ID --to--> SDID, IOMMU ID assignment when programming rules.

[sameo]

we should specifically describe the role of the RDSM w.r.t the IOMTT programming - this may need a seperate interface instead of saying that the RDSM intercepts?

That would be cleaner indeed. That would be an IOMTT SBI interface then?

So, COVH is the interface between the host and the TSM and covers the interaction of binding a TDI which is under the purview of a RP/IOMMU to a TVM. In that sense, COVH assumes a 1:1 interaction between the hosting domain and the confidential domain TSM.

Right. An implicit RDSM interception is not ideal in that sense, and also because it implies a semantic knowledge of the CoVE-IO ABI from the RDSM implementation.

The RDSM OTOH owns programming of the MTT to enforces sup. dom. isolation and that the IOMMUs memory-mapped programming regions are access-restricted to the sup. dom. the IOMMU has been assigned to. So the IOMMU un/assignment ABI should really be serviced by the RDSM. The second interface the RDSM must support is the programming of the SDCL - which maps an IO request to the SDID and IOMMU ID - so this ABI to program the IOMTT is also to be serviced by the RDSM. Through this second ABI function, the RDSM will enforce consistency of the Deviceid/IDE Stream ID --to--> SDID, IOMMU ID assignment when programming rules.

That makes sense to me. So we should go ahead and start defining that ABI in the Smmtt spec?

[rsahita]

Maybe more apt to add this abi sub-extension in this spec (cove-io)?

[sameo]

Maybe more apt to add this abi sub-extension in this spec (cove-io)?

Yes, that's probably the best place to define those.

I'll park this as a 0.3.0 item for the specification.