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

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

Jason Gunthorpe wrote:
> On Thu, Mar 12, 2026 at 09:11:32PM -0700, Dan Williams wrote:
> > Greg KH wrote:
> > > On Mon, Mar 02, 2026 at 04:01:51PM -0800, Dan Williams wrote:
> > > > An "accepted" device is one that is allowed to access private memory within
> > > > a Trusted Computing Boundary (TCB). The concept of "acceptance" is distinct
> > > > from other device properties like usb_device::authorized, or
> > > > tb_switch::authorized. The entry to the accepted state is a violent
> > > > operation in which the device will reject MMIO requests that are not
> > > > encrypted, and the device enters a new IOMMU protection domain to allow it
> > > > to access addresses that were previously off-limits.
> > > 
> > > Trying to mix/match "acceptance" with "authorized" is going to be a
> > > nightmare, what's the combination that can happen here over time?
> > 
> > I do think Linux needs to mix/match these concepts. "Authorization" is a
> > kernel policy to operate a device at all. "Acceptance" is a mechanism
> > to operate a device within a hardware TCB boundary.
> 
> I'm not sure about these words either, I would revise your table to be
> more OS centric, the device can be in one of four security levels:

I like this framing.

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

It does strike me that this value could be used to convey whether a
given arch's IOMMU driver indeed arranges for devices to be IOMMU
blocked while driver detached. In that case you could see, "oh, devices
are not DMA blocked by default" as we talked about in the ATS-always-on
thread [1].

[1]: http://lore.kernel.org/20260128130520.GV1134360@nvidia.com

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

> 2 In use, no attacks from the device
>   The device does what the driver says and is not hostile. The driver
>   does not have to defend itself, the IOMMU can run in faster & lower
>   security modes (ATS on, DMA-FQ, Identity, still CC shared only)
>    * Basically our default security level today
> 
> 3 In use, no attacks, and access to CC private memory
>   Like #2 and now the IOMMU allows access to CC private memory too.

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

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

> [*] I'm inclunding all attacks with "hostile device", including MIM on
> the PCIe link, compromised/fake device, attacks from a VMM through a
> virtual device, etc.
> 
> From a CC VM perspective 0 is at boot, 1 is an out of TCB device, 2
> doesn't exist (without TDISP there is no way to keep the
> hypervisor from attacking?),

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.

> and 3 is a full accepted TDSIP device.
> 
> #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.

> From a uAPI perspective I'm not sold on having two bools, I think a
> level string would be more flexible. TSM and CC properties are
> orthogonal, except you can't select #3 without the TSM saying it is in
> RUN.

Perhaps the concern is less 2 bools in the uAPI and more the concern
that 'struct pci_dev::untrusted', 'struct tb_switch::authorized',
'struct usb_dev::authorized' and this new 'struct
device_private::cc_accepted' are getting convoluted.

> Internally we'd probably turn that dev->trusted thing into an
> enum and teach the iommu layer to treat it more dynamically.

I will take a stab at some patches in this direction and at least
demonstrate how 'struct pci_dev::untrusted' can be merged with what CC
wants to add on top.