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

["Dan Williams (nvidia)" <djbw@kernel.org>]

Jason Gunthorpe wrote:
> 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.

T=1 and ADVERSARY are independent for link encryption and private MMIO.
In other words the device is placed into the TDISP RUN state independent
of its trust level. Downstream accesses to the device must have T=1, and
its upstream accesses will have T=1, but with force_dma_unencrypted() ==
true.

The only combination missing is T=1 with force_dma_unencrypted() == false &&
VIOMMU enforcing IOMMU_DOMAIN_DMA.

> 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.

Two notes,

1/ that is effectively how the UNSET level behaves. If the
bus has not set ADVERSARY before device_add() then the default behavior
is the AUTO level. Where AUTO means all of the automatic privileges a
device can be offered without needing any other coordination.

2/ The ambiguity and conflict occurs at ->dma_configure() time when the
bus and IOMMU layer want to reject the device's access to some privilege
by failing. When FULL is defined as !ADVERSARY then it is difficult to
describe the semantics when FULL trust honors rejections to private DMA
and when it falls back to shared operation.

The above more points to a need to have an explicit trust level for
adversarial private memory access. The address spaces are distinct
assets with different levels of trust.

UNSET: bus picks initial level, or leaves it to the device_core().
NONE:
ADVERSARY: Device can be in T=0, or T=1 mode (UNLOCKED, or RUN).
AUTO: Could rename this to be FULL or ALL or DEFAULT, I still keep
      coming back to the "AUTO" name because the privileges are not
      uniform based on the IOMMU / DMA topology and device capability.
      Again, the TDISP state is independent. The TSM driver does
      not get called to gatekeep and verify access in this mode.
TCB_ADVERSARY: or PRIVATE_ADVERSARY. Device can access private platform
	       resources iff an enforcing IOMMU is present.
TCB: or PRIVATE_FULL, automatically enable all access privileges
     including private memory access.

Direct-dma to private memory without a Secure VIOMMU present
requires "TCB".

> 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.

Yes, a mode that can setup IOMMU_DOMAIN_DMA for private memory
makes sense. It needs a new trust level to distinguish if the
device is trusted to access one or both address spaces.

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

I think it is important to distinguish that the CC case adds another
class of memory to the trust decision.

> 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.

This discussion gets strained for me when T=1 is used to mean both
"device is in TDISP RUN (with link encryption and private MMIO)" and
"device is in TDISP RUN + force_dma_unencrypted() == false".

As implemented, userspace can confirm the former before setting the
trust. The latter only gets confirmed / denied at ->dma_configure()
time, because that is the point at which driver policy has been applied
to set the operational trust level.

Otherwise, full bi-directional T=1 before setting the trust would
require an IOMMU to be blocking the device until that final confirmation
point. Given that is not always available the proposal is to defer
acknowledging the trust level with the TSM until ->dma_configure().

As far as userspace is concerned it has enabled T=1 at the device and
validated device evidence. Any failures to operate the device from that
point are either the TSM finding fault with the evidence the CC VM is
relying upon, or, in the new TCB_ADVERSARY case, the IOMMU layer says,
"no IOMMU present to enforce IOMMU_DOMAIN_DMA".

> 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.

Agree that "TCB" alone is insufficient per above. However, a new
"trust when/if" ABI does not appear to scale.

Userspace policy simply needs to contend with the mechanisms that
"Device Core, BUS, IOMMU or TSM driver may fail to enable a device at a
given trust level".

NONE: Device core rejects device operation
ADVERSARY: reject device operation if an IOMMU to set IOMMU_DOMAIN_DMA
           not available (not in current patches)
AUTO: no rejections, but no private memory access either
TCB_ADVERSARY: reject device operation if IOMMU_DOMAIN_DMA not
	       available, or TSM rejects the evidence used to enable
               private memory access.
TCB: reject device operation if TSM rejects chosen evidence

Overrides and bypasses for those rejection decisions belong with
their respective drivers. For example, if a paravisor is handling
TDISP then there is no TSM driver to reject TCB operation.
Similarly ->dma_configure() when no IOMMU is present is a nop
today. New enabling could turn to enforcing, or userspace policy
otherwise understands the risks.