On Mon, Jan 20, 2025 at 08:45:51PM +1100, Alexey Kardashevskiy wrote:
For CC I'm expecting the KVM fd to be the handle for the cVM, so any RPCs that want to call into the secure world need the KVM FD to get the cVM's identifier. Ie a "bind to cVM" RPC will need the PCI information and the cVM's handle.
And keep KVM fd open until unbind? Or just for the short time to call the PSP?
iommufd will keep the KVM fd alive so long as the vIOMMU object exists. Other uses for kvm require it to work like this.
But it also seems to me that VFIO should be able to support putting the device into the RUN state without involving KVM or cVMs.
AMD's TDI bind handler in the PSP wants a guest handle ("GCTX") and a guest device BDFn, and VFIO has no desire to dive into this KVM business beyond IOMMUFD.
As in my other email, VFIO is not restricted to running VMs, useful things should be available to apps like DPDK.
There is a use case for using TDISP and getting devices up into an ecrypted/attested state on pure bare metal without any KVM, VFIO should work in that use case too.
Jason
[ My ears have been burning for a couple months regarding this thread and I have finally had the chance to circle back and read through all the discussion on PATCH 01/12 and this PATCH 08/12, pardon the latency while I addressed some CXL backlog ]
Jason Gunthorpe wrote:
On Mon, Jan 20, 2025 at 08:45:51PM +1100, Alexey Kardashevskiy wrote:
For CC I'm expecting the KVM fd to be the handle for the cVM, so any RPCs that want to call into the secure world need the KVM FD to get the cVM's identifier. Ie a "bind to cVM" RPC will need the PCI information and the cVM's handle.
And keep KVM fd open until unbind? Or just for the short time to call the PSP?
iommufd will keep the KVM fd alive so long as the vIOMMU object exists. Other uses for kvm require it to work like this.
But it also seems to me that VFIO should be able to support putting the device into the RUN state without involving KVM or cVMs.
AMD's TDI bind handler in the PSP wants a guest handle ("GCTX") and a guest device BDFn, and VFIO has no desire to dive into this KVM business beyond IOMMUFD.
As in my other email, VFIO is not restricted to running VMs, useful things should be available to apps like DPDK.
There is a use case for using TDISP and getting devices up into an ecrypted/attested state on pure bare metal without any KVM, VFIO should work in that use case too.
Are you sure you are not confusing the use case for native PCI CMA plus PCIe IDE *without* PCIe TDISP? In other words validate device measurements over a secure session and set up link encryption, but not enable DMA to private memory. Without a cVM there is no private memory for the device to talk to in the TDISP run state, but you can certainly encrypt the PCIe link.
However that pretty much only gets you an extension of a secure session to a PCIe link state. It does not enable end-to-end MMIO and DMA integrity+confidentiality.
Note that to my knowledge all but the Intel TEE I/O implementation disallow routing T=0 traffic over IDE. The host bridge only accepts T=1 traffic over IDE to private memory which is not this "without any KVM" use case.
The uapi proposed in the PCI/TSM series [1] is all about the setup of PCI CMA + PCIe IDE without KVM as a precuror to all the VFIO + KVM + IOMMUFD work needed to get the TDI able to publish private MMIO and DMA to private memory.
[1]: http://lore.kernel.org/174107245357.1288555.10863541957822891561.stgit@dwill...
On Tue, Mar 11, 2025 at 06:37:13PM -0700, Dan Williams wrote:
There is a use case for using TDISP and getting devices up into an ecrypted/attested state on pure bare metal without any KVM, VFIO should work in that use case too.
Are you sure you are not confusing the use case for native PCI CMA plus PCIe IDE *without* PCIe TDISP?
Oh maybe, who knows with all this complexity :\
I see there is a crossover point, once you start getting T=1 traffic then you need a KVM handle to process it, yes, but everything prior to T=0, including all the use cases with T=0 IDE, attestation and so on, still need to be working.
In other words validate device measurements over a secure session and set up link encryption, but not enable DMA to private memory. Without a cVM there is no private memory for the device to talk to in the TDISP run state, but you can certainly encrypt the PCIe link.
Right. But can you do that all without touching tdisp?
However that pretty much only gets you an extension of a secure session to a PCIe link state. It does not enable end-to-end MMIO and DMA integrity+confidentiality.
But that is the point, right? You want to bind your IDE encryption to the device attestation and get all of those things. I thought you needed some TDISP for that?
Note that to my knowledge all but the Intel TEE I/O implementation disallow routing T=0 traffic over IDE.
I'm not sure that will hold up long term, I hear alot of people talking about using IDE to solve all kinds of PCI problems that have nothing to do with CC.
The uapi proposed in the PCI/TSM series [1] is all about the setup of PCI CMA + PCIe IDE without KVM as a precuror to all the VFIO + KVM + IOMMUFD work needed to get the TDI able to publish private MMIO and DMA to private memory.
That seems reasonable
Jason
linaro-mm-sig@lists.linaro.org
-
Dan Williams -
Jason Gunthorpe