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.
