Re: [RFC PATCH 12/21] KVM: IOMMUFD: MEMFD: Map private pages

[Dan Williams <dan.j.williams@intel.com>]

Jason Gunthorpe wrote:
> On Tue, Sep 03, 2024 at 01:34:29PM -0700, Dan Williams wrote:
> > Jason Gunthorpe wrote:
> > > On Fri, Aug 30, 2024 at 01:20:12PM +0800, Xu Yilun wrote:
> > > 
> > > > > If that is true for the confidential compute, I don't know.
> > > > 
> > > > For Intel TDX TEE-IO, there may be a different story.
> > > > 
> > > > Architechturely the secure IOMMU page table has to share with KVM secure
> > > > stage 2 (SEPT). The SEPT is managed by firmware (TDX Module), TDX Module
> > > > ensures the SEPT operations good for secure IOMMU, so there is no much
> > > > trick to play for SEPT.
> > > 
> > > Yes, I think ARM will do the same as well.
> > > 
> > > From a uAPI perspective we need some way to create a secure vPCI
> > > function linked to a KVM and some IOMMUs will implicitly get a
> > > translation from the secure world and some IOMMUs will need to manage
> > > it in untrusted hypervisor memory.
> > 
> > Yes. This matches the line of though I had for the PCI TSM core
> > interface. 
> 
> Okay, but I don't think you should ever be binding any PCI stuff to
> KVM without involving VFIO in some way.
> 
> VFIO is the security proof that userspace is even permitted to touch
> that PCI Device at all.

Right, I think VFIO grows a uAPI to make a vPCI device "bind capable"
which ties together the PCI/TSM security context, the assignable device
context and the KVM context.

> > It allows establishing the connection to the device's
> > security manager and facilitates linking that to a KVM context. So part
> > of the uAPI is charged with managing device-security independent of a
> > VM
> 
> Yes, the PCI core should have stuff for managing device-secuirty for
> any bound driver, especially assuming an operational standard kernel
> driver only.
> 
> > and binding a vPCI device involves a rendezvous of the secure-world
> > IOMMU setup with secure-world PCI via IOMMU and PCI-TSM
> > coordination.
> 
> And this stuff needs to start with VFIO and we can figure out of it is
> in the iommufd subcomponent or not.
> 
> I'd really like to see a clearly written proposal for what the uAPI
> would look like for vPCI function lifecycle and binding that at least
> one of the platforms is happy with :)
> 
> It would be a good starting point for other platforms to pick at. Try
> iommufd first (I'm guessing this is correct) and if it doesn't work
> explain why.

Yes, makes sense. Will take a look at that also to prevent more
disconnects on what this PCI device-security community is actually
building.