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

[Greg KH <gregkh@linuxfoundation.org>]

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?

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:

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

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

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


> +
>  };
>  #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.

> +/**
> + * 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?

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?

thanks,

greg k-h