On Fri, Aug 30, 2024 at 01:47:40PM +1000, Alexey Kardashevskiy wrote: > > > > Yes, we want a DMA MAP from memfd sort of API in general. So it should > > > > go directly to guest memfd with no kvm entanglement. > > > > > > A uAPI like ioctl(MAP_DMA, gmemfd, offset, iova) still means userspace > > > takes control of the IOMMU mapping in the unsecure world. > > > > Yes, such is how it seems to work. > > > > It doesn't actually have much control, it has to build a mapping that > > matches the RMP table exactly but still has to build it.. > > Sorry, I am missing the point here. IOMMU maps bus addresses (IOVAs) to host > physical, if we skip IOMMU, then how RMP (maps host pfns to guest pfns) will > help to map IOVA (in fact, guest pfn) to host pfn? Thanks, It is the explanation for why this is safe. For CC the translation of IOVA to physical must not be controlled by the hypervisor, for security. This can result in translation based attacks. AMD is weird because it puts the IOMMU page table in untrusted hypervisor memory, everyone else seems to put it in the trusted world's memory. This works for AMD because they have two copies of this translation, in two different formats, one in the RMP which is in trusted memory and one in the IO page table which is not trusted. Yes you can't use the RMP to do an IOVA lookup, but it does encode exactly the same information. Both must agree on the IOVA to physical mapping otherwise the HW rejects it. Meaning the IOMMU configuration must perfectly match the RMP configuration. Jason
