Re: [PATCH v8 12/23] dma: swiotlb: pass mapping attributes by reference

[Jason Gunthorpe <jgg@nvidia.com>]

On Mon, Aug 10, 2026 at 03:18:03PM +0100, Robin Murphy wrote:

> Cool. So in fact that puts us in an interesting position for now where
> non-CoCo "untrusted" (i.e. external) devices should have IOMMU translation
> forced on by default, while CoCo "unaccepted" devices (i.e. those which do
> have a mechanism to transition into a T=1 or equivalent state) should *not*
> try to use an associated IOMMU, on the assumption that it may only work for
> T=1 traffic. All the more reason to sort these abstractions out so we can
> make the right distinctions clearly :)

I think the guest flow works out fairly logically:

1) At boot the IOMMU core always setups blocking translation. No more
   auto-attaching paging or identity domains at probe time [optional,
   but default on for CC guest]
   * This means devices that can have their DMA disabled do
   * Additionally T=1 capable devices have their T=1 DMA blocked by
     the CC platform itself. eg RMM is to leave the T=1 STE set to
     blocking at VM boot until commanded otherwise.

   Aside from CC this also goes hand in hand with DRTM support in the
   kernel where we do want to carry over the DMA access block from the
   secure launch until the system, ideally via userspace policy, has
   approved the device.

2) Before probing a driver we synchronize the TDISP state, IOMMU
   and configure the DMA API:
    a. If no iommu, then DMA API is in physical
    b. If both device and IOMMU same-T then DMA API follows IOMMU configuration:
         - DMA API is physical if IOMMU configuration is identity
         - DMA API is dma-iomu if paging
         - IOMMU sets the proper domain for the DMA API, removes the
           blocking
    c. If device and iommu have different T state then assume no iommu
       and DMA API is physical
2b) For T=1 capable devices this is the moment we tell the CC platform
    to permit DMA

3) The DMA API configuration follows per-device flags:
    - Using IOMMU: Use dma-iommu not physical
    - Using T=0/1: Replaces 'force dma unencrypted'. Ie T=0 uses
      swiotlb to get CC shared memory.
    - adversarial: Replaces pdev->trusted/etc. Causes IOMMU and
      SWIOTLB to bounce buffer partial pages.
      Causes iommu to prefer paging not identity.

4) After removing a driver we restore the IOMMU back to blocking. The
   CC platform is told to block DMA again, if it can.

If we ever do decide to support dual iommu then #2 would be the point
we swap the iommu control between the T=0/1 iommu.

> (And while untrusted vIOMMUs for purely-untrusted devices in CoCo
> environments would be pretty straightforward as well, I guess we might need
> some sort of acceptance status for trusted vIOMMU devices themselves?
> Hmm...)

That should fall into the overall plan for device acceptance. We want
the kernel to have a small policy of devices it would accept prior to
the initrd. Untrusted versions of iommu (and others) should not auto
probe.

The initrd can then decide if it wants to probe the untrusted
iommu. Probably it does not right now since we haven't done any
security analysis on the SMMUv3 being operated by a hostile
hypervisor. ARM should be OK here, a modular SMMUv3 will achieve this
trivially. x86 will have a harder time.

Userspace will run its acceptance flow and figure out what drivers to
bind. Along the way userspace will record what it is accepting in a
measurement log.

So, lots of little steps along the path. I imagine various series
something like:

- Basic version of #1 and #2 to generally defer opening DMA till
  probe
- TSM APIs to support setting T=1 and doing the evidence suff
- T=1 flag for devices supported by IOMMU and DMA API, replacing force
  dma unencrypted
- Userspace driven policy control over device binding
- General trust level concept, including an "adversarial" trust level
  which will trigger various auto configuration and mitigations
- tsm_mr improvmements
- adversarial T=1 devices, eg SWIOTLB still bounce buffers but has to
  support a private pool

Regards,
Jason