Re: [PATCH 00/15] Device Evidence and Trust for PCI Security Protocol (TDISP)

[Jason Gunthorpe <jgg@ziepe.ca>]

On Sun, Jul 05, 2026 at 03:08:04PM -0700, Dan Williams wrote:
> * NONE: no usage of the device unless the trust is explicitly overridden
>   by user policy specified via a driver flag, module flag, or uapi (TBD).
> 
> * ADVERSARY: needs acknowledgement from the bus and IOMMU / DMA layers
>   that the device is limited to strict IOMMU translation behavior. Drivers
>   can use this as a signal to limit functionality. This designation
>   implies follow-on IOMMU and bus enabling work for features like
>   arranging for the device to attach to a blocked IOMMU domain when
>   detached from a driver.
> 
> * AUTO: typical / historical Linux driver model.
> 
> * TCB: a trust level that only exists in Confidential Computing
>   environments. When acked by the IOMMU / DMA layer it enables the device
>   to issue direct-DMA to private/encrypted addresses or otherwise attach to
>   a secure vIOMMU within the TCB.

I'm not sure I entirely like this one, certainly it needs to be
possible to have both T=1 and ADVERSARY together.

Arguably the T=0/1 decision is much more like link encryption, it
effects the transport of the DMA into the CPU. That it also impacts
how the VIOMMU works is the only thing that make it sort of
trust-like in this model.

I'd also argue this list is missing "FULL" trust, which is the
historical Linux behavior for a normal device. AUTO should be
selecting between FULL/ADVERSARY based on things like the ACPI/etc as
it does today.

In a CC VM if we have a T=0 device we probably want to operate it with
ADVERSARY (there is no T=0 VIOMMU so this is equivilent to FULL)

For a T=1 device we need to have the choice of FULL or ADVERSARY. When
a VIOMMU is present ADVERSARY will further restrict the T=1 traffic as
a defense in depth.

So, it is really necessary to have "TCB" here?

If the trust level is reduced to just be a command to the kernel how
it should operate the device then it would be up to userspace to
confirm things like T=1 before setting the trust. The kernel would
have to set the trust to NONE when security sensitive changes are
detected.

If we still want a kernel-side policy gate, eg kernel will not
progress unless T=1 is met, then I think that would be better as an
independent pair'd policy field, ie
   trust=FULL when policy=T=1, LINK_ENCRYPTION=1, etc

As bundling the two into "TCB" is probably going to turn problematic
as we have more and more combinations of policy conditions.

Jason