On Tue, Sep 03, 2024 at 10:03:53AM +1000, Alexey Kardashevskiy wrote: > > > On 3/9/24 09:52, Jason Gunthorpe wrote: > > On Mon, Sep 02, 2024 at 11:09:49AM +1000, Alexey Kardashevskiy wrote: > > > On 30/8/24 22:35, Jason Gunthorpe wrote: > > > > 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. > > > > > > It is exactly the same because today VFIO does 1:1 IOVA->guest mapping on > > > x86 (and some/most other architectures) but it is not for when guests get > > > hardware-assisted vIOMMU support. > > > > Yes, you are forced into a nesting IOMMU architecture with CC guests. > > Up to two I/O page tables and the RMP table allow both 1:1 and vIOMMU, what > am I forced into, and by what? A key point of CC security is that the hypervisor cannot control the IOVA translation. AMD is securing non-viommu by using the RMP to limit the IOVA translation to 1:1 But, viommu models require a secured non 1:1 mapping. How do you intend to secure this other than using actual iommu nesting? Presumably relying on the PSP to program the secure DTE's GCR3 pointer. Jason
