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

[Greg KH <gregkh@linuxfoundation.org>]

On Thu, Mar 26, 2026 at 09:00:46AM -0300, Jason Gunthorpe wrote:
> 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.

That is what I am going to _require_ here :)

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

I agree, that's a good way of putting this.

greg k-h