Re: [PATCH v7 10/16] iommufd: Add the vdevice TSM request ioctl

[Jason Gunthorpe <jgg@nvidia.com>]

On Fri, Oct 30, 2026 at 07:41:36AM +0000, Tian, Kevin wrote:

> Then if your suggestion of using the attestation subsystem here
> can work, those OBJECT related operations are generalized too.
> 
> In the end the set of vendor specific definition here might be small.

Yeah having now looked more closely at what CCA requires this is my
feeling. It looks like it needs nothing beyond what an attestation fd
would provide. Possibly TDI state if we don't roll that into the
attestation uapi.

> > > > My guesses with no information
> > > > 1) VALIDATE_MMIO why would the hypervisor ever need this? Guest
> > > >    validates MMIO through secure communication to the secure world.
> > > >
> > >
> > > With VFIO PCI BARs backed by guest_memfd, the VMM can validate that the
> > > IPA and PA values provided by the guest belong to the VFIO device.
> > 
> > Why? Who cares? It isn't a trusted validation, and there is a RSI that
> > duplicates this?
> 
> TDX doesn't require this. It's a guest call directly to the secure world.

Yeah, if we need to know the actual current memory shared/private
layout after a TDISP state change that should be a first class API,
possibly in VFIO.

VFIO already has this information because it needs it to do the
guestmemfd/etc invalidations that Intel requires.

> > And then the seq numbers check that this went through OK?
> 
> which seq numbers in your mind?

CCA uses seq numbers to help secure the RHI. It looks broadly like the
guest counts the number of times it does operations and then the RHI
relays those operations through the hypervisor. Guest detects
tampering by checking the sequences are right through its own secure
channel, along with hashes of things..

Like it counts the number of lock/unlock commands. VMM issues a rouge
unlock guest can detect it.

> > I think the bigger issue was it had to use the VDEV flavour not the
> > PDEV flavor of RMM commands, and it isn't obvious how we switch from
> > PDEV to VDEV mode on the hypervisor..
> 
> Can you elaborate this part in a general way? Want to better understand it
> in the TDX context...

At least in CCA there are two sets of APIs into RMM for doing SPDM
stuff.

One is for the physical device and one is for the virtual device/TDI.

You have to use the right one for the right use case, the VMM has to
relay into to the virtual device API, while a non-VM bare metal host
has to use the physical to do attestation.

The full best attestation flow for a system would be something like:

 1) Bare metal OS does DRTM and gets into Linux
 2) Linux leaves drivers unbound and DMA disabled into the
    initrd/rootfs
 3) Every PCI device has a TSM connected. SPDM established. Link IDE
    setup. PCI device SPDM evidence/measurements collected and logged.
 4) VFIO driver is attached
 ** Now we can attest the hypervisor is secure, untampered, and has
    the correct inventory of PCIe devices.
 5) VMM starts a TVM
 6) TVM does DRTM and gets into Linux
 7) Repeat #2
 8) Repeat #3, except we are doing lock/run instead of Link
    IDE. Measurements are still logged (eg to a RTMR)
 9) Real guest driver is bound and starts running
 ** Now we can attest the guest is secure, untamperd, and has the
    correct inventory of PCIe devices

So on the hypervisor side we have two logical attestation FDs, one is
manipulating the bare metal PCI device intending to bind a bare metal
driver.

The other is the relay for the VMM to implement the guest API to
control SPDM, intending to operate the PCIe device as a TDI in TDISP
mode.

My suggestion recently was to reduce all of this to a single operation
'get attestation fd' inside the iommufd vdevice which returns an FD
configured to do the TDI phase for the VMM to use. It presents the
same uniform SPDM API we have everywhere. The VMM would have to form
that into the VMM Side of whatever arch specific protocol is carrying
it to the guest to proxy it into the guest's Attestation subsystem.

Some of if that will work depends on how the security protocol works,
like the seq numbers for CCA. That has to map perfectly onto the
attestation uAPI so that the VMM is causing only the actions to happen
that it is required to do..

Jason