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

[Jason Gunthorpe <jgg@ziepe.ca>]

On Mon, Jul 06, 2026 at 01:55:12PM -0700, Dan Williams (nvidia) wrote:
> 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. 

That's the right thing

> Downstream accesses to the device must have T=1, and
> its upstream accesses will have T=1, but with force_dma_unencrypted() ==
> true.

That should never happen. Once in RUN force_dma_unencrypyted() ==
false, it has nothing to do with the trust level.

Even if you set ADVERSARY it should still be bouncing partial page
DMAs into private memory. The point of running something like this is
to remove the shared memory attack surface - ie the hypervisor SW. The
attack surface is reduced to the device itself by remaining in shared
memory.

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

I think my other remark about two enums is some of the issue, the
policy can have things like UNSET or AUTO, but once the driver starts
to probe an in-effect mode should be computed and be concrete. Having
a driver run with a trust mode of AUTO or UNSET is just confusing.

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

Given that the trust level shouldn't impact force_dma_unencrypted(),
the only thing left is to setup the IOMMU differently, and maybe
operate a driver in a hardened mode or something like that.

I don't see what the TCB is supposed to be changing here.

That leaves it just as a policy gate to check that T=1, I'm not sure
if that is worthwhile enough for dedicated UAPI?

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

Yeah, we can keep adding more modes to make a big cross product, but
I do wonder if this is going to get too big..

IDK, maybe it should be a bitmap instead of a level?

bit 0 = Force Disable
bit 1 = Device is adversarial:
           - Enable strong IOMMU protections
           - Enable driver protections
bit 2 = Require T=1
bit 3 = Require IOMMU
bit 4 = Require DMA/MMIO security (eg Link IDE)

Where value 0 means the current level of full trust.

It is a little easier to explain what each thing is doing and easier
to add new things

Then from a sysfs perpsective the policy would have special string
values like 'use bus default'

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

It means both things though, we really must not run with
force_dma_unencrypted() = true when T=1, that's pointless and harmful.

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

?? If you have no iommu the instance you set T=1 and do the platform
step to activate DMA the device has 100% acess to all
memory. force_dma_unencrypted() does nothing to constrain device
access, it is all about accommodating an addressing limitation.

ARM at least has a dedicated call to enable DMA. It would be nice to
place that call right before the driver probes so DMA remains off
until we commit to using the device. Maybe other platforms have the
same - but I'm not sure it is *essential* as the point of setting RUN
can reasonably be the acceptance point.

> 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

What does "TSM rejectes chosen evidence" mean? Kernel isn't supposed
to be evaluating evidence?

Jason