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

On 9/7/26 23:36, Jason Gunthorpe wrote:
> 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.

afaik you cannot have RUN and T=0 DMA at the same time. You can though have C=0 (i.e. IOMMU <-> memory in the plain).


> 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

I configure my hw to allow "accept" (== T=1 for DMA and MMIO) but still only allow unencrypted guest memory for DMA (set vTOM to 0 to say "all unencrypted) if the driver was loaded with "trust" other than "full" (and this series does not call the enable_dma() hook if not "full", Dan is changing it though) so the module parameter works...

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

"echo 1 > unlock" should do that (but also stops encrypted MMIO) or we want a finer knob?

>     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

This makes the module's "trust" parameter useless, right?


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

-- 
Alexey