search

riscv-non-isa / riscv-ap-tee-io

This TG will define AP-TEE-IO ABI extensions to provide Confidential VM-assigned devices with secure direct access to confidential memory as well as MMIO, removing the dependence on para-virtualized I/O.
https://jira.riscv.org/browse/RVG-144
Creative Commons Attribution 4.0 International
8 stars 4 forks source link

[Qualcomm feedback] 7.3.2. IDE Link - flow #87

Open jyao1 opened 5 months ago

jyao1 commented 5 months ago

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 commented 2 months ago

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

rsahita commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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

sameo commented 1 month ago

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.