From: Jason Gunthorpe jgg@nvidia.com Sent: Tuesday, August 6, 2024 7:23 AM
On Mon, Aug 05, 2024 at 02:24:42AM +0000, Tian, Kevin wrote:
According to [3],
" With SNP, when pages are marked as guest-owned in the RMP table, they are assigned to a specific guest/ASID, as well as a specific GFN with in the guest. Any attempts to map it in the RMP table to a different guest/ASID, or a different GFN within a guest/ASID, will result in an RMP nested page fault. "
With that measure in place my impression is that even the CPU's GPA translation can be controlled by the unsecure world in SEV-SNP.
Sure, but the GPA is the KVM S2, not the IOMMU. If there is some complicated way to lock down the KVM S2 then it doesn't necessarily apply to every IOVA to GPA translation as well.
The guest/hypervisor could have a huge number of iommu domains, where would you even store such granular data?
About the only thing that could possibly do is setup a S2 IOMMU identity translation reliably and have no support for vIOMMU - which doesn't sound like a sane architecture to me.
According to the SEV-TIO spec there will be a new structure called Secure Device Table to track security attributes of a TDI and also location of guest page tables. It also puts hardware assisted vIOMMU in the TCB then with nested translation the IOMMU S2 will always be GPA.
It is not insurmountable, but it is going to be annoying if someone needs access to the private pages physical address in the iommufd side.
Don't know much about SEV but based on my reading it appears that it is designed with the assumption that GPA page tables (both CPU/IOMMU S2, in nested translation) are managed by untrusted host, for both shared and private pages.
Probably AMD folks can chime in to help confirm. 😊