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

[Jason Gunthorpe <jgg@ziepe.ca>]

On Wed, Jul 08, 2026 at 07:45:09PM -0700, Dan Williams (nvidia) wrote:
> > force_dma_unencrypted() does not *prevent* device access to private
> > memory and provides no security properties on its own. It's only
> > purpose is to inform the DMA API what the HW restrictions are for
> > doing DMA.
> 
> Right, to be clear, this mode's security properties come from never
> asking the TSM to enable private DMA while the device is in RUN.

Ok, that's a twist I hadn't thought about. I don't see a reason to
support a driver probed with RUN but T=1 DMA disabled by the TSM.

Still, if we do this, I think having the TSM deal with it is probably
better than making a cross product of the trust level, something like:

 echo only-shared-dma > $pdev/tsm/accept

So maybe accept should be tweaked:

 echo full > $pdev/tsm/accept

? It doesn't matter much

> > > echo 1 > $pdev/tsm/accept
> > 
> > And now it is RUN. So I don't see the issue with enabling DMA at the
> > same time as gonig to RUN? (though defering it to driver probe would
> > be a very nice touch as well)
> 
> It requires "accept" to consider the trust level. E.g. what does it mean
> to do something like change requirements after accept?

> echo full $pdev/trust
> echo 1 > $pdev/tsm/accept
> echo adversary > $pdev/trust

> In that scenario this now adversary device may have been allowed to
> operate without an enforcing vIOMMU, and needs to unlock the device to
> correct that.

If accept enables DMA then it is up to userspace to ensure all policy
objectives are met before accepting, not after.

I think the statement kernel makes to userspace is the moment it
writes trust or accept the kernel is free to take action on it. ie
don't write a trust or accept until you mean it.

> > > There are also buses and paravisors that may know that private-DMA is
> > > enabled for a device by construction. In that case it is also a "trusted
> > > to access" signal, and not a "required to access" signal.
> > 
> > In this case they wire force_dma_unencrypted()=false.
> 
> Yeah, I just need a scheme where modular bus providers do not end up
> compromising the private / unexported method of changing the flag that
> force_dma_unencrypted() consumes.

Yeah, the bus and TSM really have to control this property, it is like
the other DMA attributes (eg dma seg boundary, etc)

> > At least if we omit the double check it can be fairly easy to add in
> > later if it really was needed for some time of use reason.
> 
> As long as IOMMU presence can be enumerated prior to acceptance, T=1
> always includes private DMA, and the T=1 status is tracked independent
> of the trust level then yes, the cross product can be avoided.

Ok. iommu has to be setup the moment the struct device is created, it
can't add on later. I *think* the iommu related sysfs ordering is done
properly before any uevents, but I haven't validated that.

> 'struct device' grows some "request" policy for trust and T=1 that can
> be changed by modules etc. 'struct device_private' grows the operational
> trust level stable under device_lock() and a new flag to reflect T=1.

I guess
 - The active trust level should be RO visible to the driver, iommu, etc
   It should be stable under a bound driver

 - The "dma require unencrypted" property needs to RO visible to the
   DMA API and stable under a bound driver. This would input where
   force_dma_unecrpyted() is in the flow [the name should align with
   all the other per-device DMA API specific properties like seg
   limit, boundary, mask, etc]

 - The requested trust policy should be internal to the driver core and
   be converted to the active trust level right before probe

 - We should have ways to enable/disable all DMA before/after probe,
   including both TSM and IOMMU approaches

Broadly all busses get some way to convert the requested trust policy
to the active trust level (eg by mixing in ACPI, etc, etc)

All busses get some way to set the "dma require unencrypted" property

IOMMU and drivers should be sensitive to the trust level

TSM is sensitive to accept, not the trust level

Userspace must ensure any security policy is met before accepting or
binding.

??

Jason