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

[Jason Gunthorpe <jgg@nvidia.com>]

On Fri, Mar 13, 2026 at 12:56:07PM -0700, Dan Williams wrote:
> > 0 Blocked and disabled
> >   The device cannot attack the system, enforced by the OS not loading a
> >   driver or mapping the MMIO and IOMMU fully blocking everything from it.
> 
> In terms of details I am trying to think through whether the device
> actually changes its ->trust level in reaction to a driver attaching, or
> whether the block and disabled state is implicit in not being driver
> bound.

I am thinking of it as an independent property. When the device is
first discovered it gets a level by default, userspace can change the
level but only when not bound. The level restricts what the kernel
will do with the device, 0 would mean "do not allow a driver to bind"

> > 1 In use, attacks from a hostile device are possible
> >   A driver can operate the device and is expected to defend against
> >   attacks from the device itself. The IOMMU restricts the device to only
> >   access driver approved data (no ATS, DMA strict only, CC shared
> >   only, interrupt remapping security, bounce partial DMA mappings, etc)
> 
> This is a better way to convey the current "force_swiotlb" settings that
> TVMs deploy in their arch code.

SWIOTLB that is needed to make the DMA API work because the device
cannot reach CC private memory is orthogonal - the TDISP state (or
lack of) should directly drive that in the DMA API.

The DMA API just wants a flag in the struct device that says if the
device can access encrypted memory or only decrypted.

> I am assuming that each bus implementation may have a different way to
> get the device to the various trust levels.

I was actually thinking no, it is just a generic orthogonal driver
core property.

> For example, the uAPI for PCI TDISP requires associating a device with a
> TSM and asking the TSM to push the device to trust level 3. 

The other way, you can't get to level 3 unless the TSM subsystem ACK's
it. So TSM independently does its bit then userspace can set the level
to 3.

If it sets RUN and 2 that should work and have some kind of meaning,
just not be super useful.

> Another bus like thunderbolt may want to imply that "authorized"
> that uses challenge response (tb_domain_challenge_switch_key)
> enables trust level 2, but otherwise only enables trust level 1.

For thunderbolt/hot plug I imagine the kernel would default all
devices to level 0. Userspace would do its thing, using whatever other
uAPIs, and then set the level to 1 or 2. Then the driver starts.

This way nothing is coupled and the kernel can offer all kinds of
different uAPI for device verification. Userspaces picks the
appropriate one and acks it with the level change.

> Yes, no mitigations against spoofing the device interface without TDISP.
> However, I would also assume that level 2 is the ATS-on trust level
> outside of TDISP cases.

Yes, level 2 would be the break where the device is required to not do
wild PCIe packets to maintain kernel integrity.

> > #2 can happen in bare metal where a OS may activate link encryption
> > and attest the device, but doesn't have CC private/shared memory.
> 
> Bare metal would still need to figure out how to send T=1 MMIO cycles
> and check with some boot attestation that it can trust its MMIO mappings
> are indeed targeting the device. So let's say trust level 2 is
> everything but private MMIO and private DMA.

bare metal has no T=1 and no "private" at all. It just sets up link
encryption, excludes a MIM, attests the peer, then opens the iommu.

Jason