Re: [PATCH 08/15] device core: Initial device trust infrastructure

[Jason Gunthorpe <jgg@ziepe.ca>]

On Sun, Jul 05, 2026 at 03:08:12PM -0700, Dan Williams wrote:
> Introduce a per-device trust concept [1]. To start, it plumbs "auto" and
> "none" levels to enable a scheme of requiring explicit opt-in to operate a
> device. This supports a Confidential Computing use case of operating a
> limited / vetted device and driver set to bootstrap the environment. It
> leans on module policy to effect changes to device's trust level.
> 
> The motivations for using module policy to effect trust are:
> 
> 1/ It exists, no new ABI needed to inject "device firewall" policy into the
>    kernel [2].
> 2/ Trust is a function of how the device is operated. A driver can be
>    trusted to carefully operate an untrusted device.
> 
> It may prove too coarse for some situations, like a driver that talks to a
> mix of trusted and untrusted devices, or a module that contains multiple
> drivers, but it is a place to start.

I'm a little confused what this is is for?

Is this how we bootstrap enough drivers to get into the initrd? Ie
is it only relavent for key boot time things like CLOCK, IRQ and IOMMU
drivers?

Once we get to the initrd eveything should be driven on a per-device
basis without anything to do with modules. We already have cases for
mlx5 where it will have to drive trusted and untrusted devices in the
same system.

> Specifically this "module trust" scheme allows for only attaching drivers
> from built-in modules by default, or modules that explicitly pass a
> "trust=auto" option by building with CONFIG_DEVICE_TRUST_NONE=y. Modules
> can also be configured to skip device attach by default by setting
> /sys/module/module/parameters/require_trust.

So I'd imagine most systems would make all modules have
require_trust=1 and some userspace compoment in the initrd will
evaluate and assign trust to devices to trigger binding and module
loading?

> The new dev->p->trust level is the operational trust level of a device. It is
> only in effect after device_add(). It is private to the device core because
> the "tcb" level is not suitable to be changed while a driver is attached to
> the device. The result force_dma_unencrypted() must be stable while the
> device is attached to its driver. That core coordination responsibility is
> not suitable to export to non-core code.

I don't think force_dma_unencrypted() should be driven from the trust
level.. It is a property of the interconnect, the trust level sits on
top of that.

> +config DEVICE_TRUST
> +	bool "Device core support for specifying trust levels for devices"
> +	help
> +	  Enable support for generic device trust levels when building a kernel
> +	  that needs to operate in the presence of potentially adversarial
> +	  devices. This is selected by buses that want to operate devices with
> +	  reduced privileges, like externally connected devices, and it is a
> +	  pre-requisite for operating devices with access to private memory in a
> +	  Confidential Computing VM. See
> +	  Documentation/ABI/testing/sysfs-kernel-iommu_groups for the type of
> +	  IOMMU enforcement in effect.
> +
> +choice
> +	prompt "Default device trust"
> +	default DEVICE_TRUST_AUTO
> +	depends on DEVICE_TRUST
> +	help
> +	  Specify the device trust level at initial attachment. Any choice other
> +	  than "Auto" assumes auditing the built-in driver set for trusted
> +	  drivers, and an enlightened userspace modprobe policy for other
> +	  devices + drivers.
> +
> +config DEVICE_TRUST_NONE
> +	bool "None"
> +	help
> +	  Devices are disallowed from attaching to a driver, and where
> +	  possible, the device is blocked by an IOMMU from accessing
> +	  assets.

It is a confusing what devices this applies to? I guess it is all
devices that are not built in?

I think it should also be in a kernel commandline, we should be able
to support a single kernel image that works for CC VM and non CC VM, I
think. You'd want the CC VM to have a kernel command line to turn on
some of this stuff.

> +choice
> +	prompt "Trust devices with built-in drivers"
> +	default BUILTIN_DEVICE_TRUST_AUTO
> +	depends on DEVICE_TRUST
> +	help
> +	  Built-in drivers always bind to devices they match. Only
> +	  select a setting other than "Auto" when building a kernel image
> +	  targeted for use in Confidential Computing or other known
> +	  adversarial environments.
> +
> +config BUILTIN_DEVICE_TRUST_AUTO
> +	bool "Auto"
> +	help
> +	  Typical historical driver model, devices eagerly attempt to attach to
> +	  a driver and deploy all available mechanisms to allow performant
> +	  direct memory access This trust level does not grant TCB privileges.

So what's the other choice?

Is this "AUTO" or is it just all builtin devices?

I think it does grant TCB privileges in some cases, ie the VIOMMU
driver that binds is in the TCB and does have T=1 equivilent DMA
access.

What we want for a CC VM is a curated set of pre-initrd devices can
auto probe:
 - Drivers internally have some kind of attestation, eg on ARM the
   VIOMMU driver is going to have to ask the RMM to prove the VIOMMU is
   legitimate
 - Drivers that don't do any DMA at all, and have approved drivers
 - Drivers that are known to be hardened for untrusted DMA


Maybe these options should be named a bit differently?

config DEVICE_TRUST  <-- If the device trust framework is compiled in at all.

DEVICE_TRUST_BUILTIN_DEFAULT = ALL, AUTO
  Decide how pre-initrd devices are handled. ALL is current Linux,
  every built in driver binds and runs, AUTO follows some module policy?

DEVICE_TRUST_MODULE_DEFUALT = AUTO, NONE
  Decide how post-initrd devices are handled. AUTO is current Linux,
  follow the ACPI/etc. NONE means the initrd must run a policy agent
  to assign trust.

> +/* SPDX-License-Identifier: GPL-2.0 */
> +/* Copyright (C) 2026 NVIDIA Corporation & Affiliates */
> +#ifndef __DEVICE_TRUST_H__
> +#define __DEVICE_TRUST_H__
> +
> +/**
> + * enum device_trust - Level of restrictions and privileges for a
> + * device. Trust is initially assigned by the bus, and the bus is
> + * responsible for coordinating transitions between trust levels with
> + * DMA/IOMMU and its own device security mechanisms.
> + *
> + * @DEVICE_TRUST_UNSET: Unregistered device object with no current bus
> + * @DEVICE_TRUST_NONE: Blocked when idle, cannot bind
> + * @DEVICE_TRUST_AUTO: All typical privileges granted

I expect there would be two enums, the policy - eg from the sysfs/etc
which is possibly this, and then the actual in-effect trust level on
the actual device which should only be DISABLED/FULL/ADVERSARY ?

So maybe call this enum device_trust_policy ?

Jason