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

On Wed, Jul 15, 2026 at 07:04:44PM +1000, Alexey Kardashevskiy wrote:
> 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.

Right, that's a great point. The devices we are making simply won't
do T=0 DMA once they are in RUN, I expect that to be the norm.

So if you disable T=1 DMA at the TSM then the device doesn't work
anymore because there was no standard way to tell the device it
shouldn't do T=1.

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

Yeah, this would be an interesting configuration from the TSM -
support T=1 but change the T=1 translation so that only shared memory
is mapped. vTOM on AMD and other tricks on other arches.

But AFIAK this isn't generally supported so I'd just leave it out for
now.

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

You shouldn't be able to unlock while a driver is bind. I'm aruging we
should also be able to keep the device in run and block all DMA
through the TSM.

> > TSM is sensitive to accept, not the trust level
> 
> This makes the module's "trust" parameter useless, right?

Yes, ideally it should act based on callbacks I think

Jason