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

[Dan Williams <dan.j.williams@intel.com>]

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.

So device could enter T=1 way in advance of the "unblock DMA" event.

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.

A bit more work, but yes, that is a cleaner separation of concerns.