On Fri, Aug 02, 2024 at 08:26:48AM +0000, Tian, Kevin wrote:
From: Jason Gunthorpe jgg@nvidia.com Sent: Thursday, June 20, 2024 10:34 PM
On Thu, Jun 20, 2024 at 04:14:23PM +0200, David Hildenbrand wrote:
- How would the device be able to grab/access "private memory", if not via the user page tables?
The approaches I'm aware of require the secure world to own the IOMMU and generate the IOMMU page tables. So we will not use a GUP approach with VFIO today as the kernel will not have any reason to generate a page table in the first place. Instead we will say "this PCI device translates through the secure world" and walk away.
The page table population would have to be done through the KVM path.
Sorry for noting this discussion late. Dave pointed it to me in a related thread [1].
I had an impression that above approach fits some trusted IO arch (e.g. TDX Connect which has a special secure I/O page table format and requires sharing it between IOMMU/KVM) but not all.
e.g. SEV-TIO spec [2] (page 8) describes to have the IOMMU walk the existing I/O page tables to get HPA and then verify it through a new permission table (RMP) for access control.
It is not possible, you cannot have the unsecure world control the IOMMU translation and expect a secure guest.
The unsecure world can attack the guest by scrambling the mappings of its private pages. A RMP does not protect against this.
This is why the secure world controls the CPU's GPA translation exclusively, same reasoning for iommu.
Jason