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

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

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.

So, the truth table of combinations would be:

accepted	authorized	result
0		0		logically and physically disconnected device

0		1		connected device, DMA is bounce buffered
				and loses confidentiality, integrity,
				and performance

1		0		logically disconnected device, but a
				relying party trusts that the device is
				not spoofing authorization.

1		1		connected device, DMA is direct and gains
				confidentiality, integrity and performance

To say it another way, when the above distinguishes "logically" vs
"physically" disconnected it is whether the device interface can be
verified to not be under adversarial control. An unaccepted device can
do limited damage, but still can bounce buffer secrets out of the TCB if
so directed.

> We need to either "trust" or "not trust" the device, and the bus can
> decide what to do with that value (if anything).  The DMA layer can then
> use that value to do:

Trust is separate. For example, there are deployed use cases today where
the device is trusted, but unaccepted. Acceptance support for those
cases is mostly a performance optimization to be able to stop performing
software encryption on top of DMA bounce buffering.

> > Subsystems like the DMA mapping layer, that need to modify their behavior
> > based on the accept state, may only have access to the base 'struct
> > device'.
> 
> ^this.

The DMA layer is not operating on a trust concept it is effectively
being told to select an IOMMU.

> > It is also likely that the concept of TCB acceptance grows beyond
> > PCI devices over time. For these reasons, introduce the concept of
> > acceptance in 'struct device_private' which is device common, but only
> > suitable for buses and built-in infrastructure to consume.
> 
> Busses are what can control this, but please, let's not make this a
> cc-only type thing.  We have the idea of trust starting to propagate
> through a number of different busses, let's get it right here, so we
> don't have to have all of these different bus-specific hacks like we do
> today.

The conflation of "trust" and "acceptance" has been the main stumbling
block of past proposals. As you have said before "kernel drivers trust
their devices". That precedent is not being touched in this proposal.
Instead, give userspace all the tools it needs to deploy policy about
when to operate a device. When it does decide to operate the device give
it the mechanism to add confidentiality, integrity and performance to
that operation.

This is a "CC-only type thing" because only CC partitions the system
into two device domains. One where "trusted unaccepted" devices can
operate without CC protections and "trusted accepted" devices can
operate with CC protections and direct DMA.

> 
> > Cc: Christoph Hellwig <hch@lst.de>
> > Cc: Jason Gunthorpe <jgg@ziepe.ca>
> > Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> > Cc: Robin Murphy <robin.murphy@arm.com>
> > Cc: Roman Kisel <romank@linux.microsoft.com>
> > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > Cc: Samuel Ortiz <sameo@rivosinc.com>
> > Cc: Alexey Kardashevskiy <aik@amd.com>
> > Cc: Xu Yilun <yilun.xu@linux.intel.com>
> > Cc: "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> > Cc: Danilo Krummrich <dakr@kernel.org>
> > Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> > ---
> >  drivers/base/Kconfig   |  4 +++
> >  drivers/base/Makefile  |  1 +
> >  drivers/base/base.h    |  9 +++++++
> >  include/linux/device.h | 22 ++++++++++++++++
> >  drivers/base/coco.c    | 58 ++++++++++++++++++++++++++++++++++++++++++
> >  5 files changed, 94 insertions(+)
> >  create mode 100644 drivers/base/coco.c
> > 
> > diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
> > index 1786d87b29e2..d4743bf978ec 100644
> > --- a/drivers/base/Kconfig
> > +++ b/drivers/base/Kconfig
> > @@ -249,4 +249,8 @@ config FW_DEVLINK_SYNC_STATE_TIMEOUT
> >  	  command line option on every system/board your kernel is expected to
> >  	  work on.
> >  
> > +config CONFIDENTIAL_DEVICES
> > +	depends on ARCH_HAS_CC_PLATFORM
> > +	bool
> > +
> >  endmenu
> > diff --git a/drivers/base/Makefile b/drivers/base/Makefile
> > index 8074a10183dc..e11052cd5253 100644
> > --- a/drivers/base/Makefile
> > +++ b/drivers/base/Makefile
> > @@ -27,6 +27,7 @@ obj-$(CONFIG_GENERIC_MSI_IRQ) += platform-msi.o
> >  obj-$(CONFIG_GENERIC_ARCH_TOPOLOGY) += arch_topology.o
> >  obj-$(CONFIG_GENERIC_ARCH_NUMA) += arch_numa.o
> >  obj-$(CONFIG_ACPI) += physical_location.o
> > +obj-$(CONFIG_CONFIDENTIAL_DEVICES) += coco.o
> >  
> >  obj-y			+= test/
> >  
> > diff --git a/drivers/base/base.h b/drivers/base/base.h
> > index b68355f5d6e3..1ae9a1679504 100644
> > --- a/drivers/base/base.h
> > +++ b/drivers/base/base.h
> > @@ -119,8 +119,13 @@ struct driver_type {
> >   * @dead: This device is currently either in the process of or has been
> >   *	  removed from the system. Any asynchronous events scheduled for this
> >   *	  device should exit without taking any action.
> > + * @cc_accepted: track the TEE acceptance state of the device for deferred
> > + *		 probing, MMIO mapping type, and SWIOTLB bypass for private memory DMA.
> >   *
> >   * Nothing outside of the driver core should ever touch these fields.
> > + *
> > + * All bitfield flags are manipulated under device_lock() to avoid
> > + * read-modify-write collisions.
> >   */
> >  struct device_private {
> >  	struct klist klist_children;
> > @@ -136,6 +141,10 @@ struct device_private {
> >  	struct driver_type driver_type;
> >  #endif
> >  	u8 dead:1;
> > +#ifdef CONFIG_CONFIDENTIAL_DEVICES
> > +	u8 cc_accepted:1;
> > +#endif
> 
> Just make this:
> 	u8 trusted:1;
> 
> no need for an #ifdef.

Ok.

> 
> 
> > +
> >  };
> >  #define to_device_private_parent(obj)	\
> >  	container_of(obj, struct device_private, knode_parent)
> > diff --git a/include/linux/device.h b/include/linux/device.h
> > index 0be95294b6e6..4470365d772b 100644
> > --- a/include/linux/device.h
> > +++ b/include/linux/device.h
> > @@ -1191,6 +1191,28 @@ static inline bool device_link_test(const struct device_link *link, u32 flags)
> >  	return !!(link->flags & flags);
> >  }
> >  
> > +/* Confidential Device state helpers */
> > +#ifdef CONFIG_CONFIDENTIAL_DEVICES
> > +int device_cc_accept(struct device *dev);
> > +int device_cc_reject(struct device *dev);
> > +bool device_cc_accepted(struct device *dev);
> > +#else
> > +static inline int device_cc_accept(struct device *dev)
> 
> No __must_hold() usage?  That's best to check this at build time, not
> just relying on:
> 
> > +{
> > +	lockdep_assert_held(&dev->mutex);
> 
> runtime checks.
> 
> Same for all the calls here.

Ok, will take a look and convert.

> > +/**
> > + * device_cc_accept(): Mark a device as able to access private memory
> > + * @dev: device to accept
> > + *
> > + * Confidential bus drivers use this helper to accept devices. For example, PCI
> > + * has a sysfs ABI to accept devices after relying party attestation.
> > + *
> > + * Given that moving a device into confidential / private operation implicates
> > + * changes to MMIO mapping attributes and DMA mappings, the transition must be
> > + * done while the device is idle (driver detached).
> > + */
> > +int device_cc_accept(struct device *dev)
> > +{
> > +	lockdep_assert_held(&dev->mutex);
> > +
> > +	if (dev->driver)
> > +		return -EBUSY;
> 
> So you are saying that once a driver is bound, it is "trusted"?  That's
> fine, but maybe you don't want to do that in the core, shouldn't that be
> a bus-specific thing?

No, per above this not about trust. This is about the fact that the
device can not switch between DMA/IOMMU and encrypted MMIO operational
models while it may have active DMA or MMIO mappings. So the check here
is to observe that the mechanism of toggling inside / outside TCB
operation is so violent as to not be something that can change while the
device is being operated by a driver.

> 
> this could then be:
> int device_trust(struct device *dev);
> int device_untrust(struct device *dev);  /* ugh, bad name, pick something else? */
> bool device_trusted(struct device *dev);
> 
> but note, do you ever want to move a device from trusted to untrusted?
> What would cause that?

Moving to unaccepted operation is when any detail that the relying party
used to make "accept" decision changed. For example, the device moves
to the ERROR security state from severe events like PCIe link encryption
loss, to modest events like the host VMM toggled the bus-master-enable
bit in the physical function's command register.

So error recovery takes the device from RUN to ERROR before it can be
transitioned back to LOCK then RUN (accepted). But also a coordinated
firmware update would need to take the device from RUN to UNLOCKED to
LOCKED (revalidate device evidence) back to RUN.