Re: [PATCH v2 03/19] device core: Introduce confidential device acceptance

[Jason Gunthorpe <jgg@nvidia.com>]

On Wed, Mar 25, 2026 at 06:27:04PM -0700, Dan Williams wrote:
> Jason Gunthorpe wrote:
> [..]
> > > Right, the potential to see in-between states concerns me because TSM
> > > uAPIs would have fully enabled the device to wreak havoc, meanwhile
> > > dev->trust is still showing the device at some lower level of trust. So
> > > I think trust modification needs to be synchronous with privileges
> > > granted/revoked.
> > 
> > If an iommu is present then the device will still be blocked even
> > though it is in RUN, I'm not sure this synchronicity is so important.
> 
> Oh, maybe we are just quibbling about where the mechanism lives. The
> "unblock DMA" step in current preliminary patches is currently behind
> the "struct pci_tsm_ops::accept()" op which also handles transitioning
> the device to RUN / T=1. It is a bus callback.
> 
> However, if the IOMMU layer is enlightened to block/unblock DMA on trust
> setting then the TDISP "unblock DMA" step can be factored out of this bus
> callback and into the IOMMU trust responder.

Yes, I would prefer this because it makes the whole IOMMU mechanism
entirely general and not tied to TDISP - which I think is sort of what
Greg is pushing on too.

> I assume this would also expect that encrypted MMIO mappings are also
> not established while trust is less than "TCB"? That would require some
> additional enabling to catch attempts to establish an encrypted mapping
> that the hardware is prepared for, but dev->trust is not, all without
> needing to modify the driver to worry about this difference. Drivers
> would just see ioremap() failure in this case.

Hmm.. I don't know if this matters. Once we decide to use the device
the MMIO should be mapped in the correct way, whatever that is.

If we decide to eventually allow a lower trust while T=1 then that
should be taken to mean the user wants all the features protecting the
communication channel but also all the IOMMU features restricting what
memory the device can access.

Remember there are two parallel things here, one is T=1 which is
designed to protect against hypervisor and physical attacks, the other
is the trust level and iommu which would be able to protect against
attacks from an attested device itself.

Even if you are in a T=1 environment you may still decide you don't
really trust the device firmware that much and would prefer to have it
more restricted.

For example, if you have a system with a NVMe drive then all the data
on the drive is probably still encrypted and has be CPU-decrypted
before it can be used. It would be reasonable to run in T=1 and attest
the drive to limit attack surface but also use the IOMMU to limit NVMe
access to only the memory used to bounce to the CPU decryption as an
additional fortification.

This is why I am tending to prefer that the kernel's view of trust
level and the physical HW capability are somewhat orthogonal
things. Even if the HW has high security the user may still prefer
that the kernel distrust.

Jason