Re: [PATCH 09/15] PCI, device core: Move "untrusted" concept to DEVICE_TRUST_ADVERSARY

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] Global device trust default is bypassed for non-PCI devices during IOMMU initialization because `device_initialize_trust()` fails to initialize `bus_trust`.
- [High] Driver binding overwrites `dev->bus_trust`, disabling dynamic IOMMU DMA protections and breaking PCI trust inheritance for downstream devices.
- [Low] Missing `#else` stub for `device_untrusted()` causes compilation errors when `CONFIG_DEVICE_TRUST` is disabled.
- [Low] `enum device_trust` is used as a value type in `struct device`, but it is neither defined nor forward-declared in `<linux/device.h>`.
--

commit e078ccf16f66fc647e7473fedd70781ac6e8fd5d
Author: Dan Williams <djbw@kernel.org>

PCI, device core: Move "untrusted" concept to DEVICE_TRUST_ADVERSARY

This commit elevates the PCI "untrusted" concept to a core device trust
level called DEVICE_TRUST_ADVERSARY. It adds a new bus_trust field to
struct device and uses it to manage trust states before device_add(),
syncing it to the private device trust structure afterwards. It updates
IOMMU and PCI subsystems to use the generic device_untrusted() interface.

> diff --git a/drivers/base/trust.c b/drivers/base/trust.c
> index 0fd494e1557dc..8efbe5c512501 100644
> --- a/drivers/base/trust.c
> +++ b/drivers/base/trust.c
> @@ -6,15 +6,28 @@
>  #include <linux/module.h>
>  #include "base.h"
>  
> +/* If the bus did not initialize trust, set a default */
>  void device_initialize_trust(struct device *dev)
>  {
> +	dev->p->trust = dev->bus_trust;
>  	if (dev->p->trust == DEVICE_TRUST_UNSET)
>  		dev->p->trust = DEVICE_DEFAULT_TRUST;
>  }

[Severity: High]
Does this bypass the global trust default for non-PCI devices?

The fallback logic updates dev->p->trust to DEVICE_DEFAULT_TRUST but leaves
dev->bus_trust as DEVICE_TRUST_UNSET (0). Since device_untrusted() strictly
evaluates dev->bus_trust, does this leave the trust uninitialized?

Furthermore, IOMMU probes devices via BUS_NOTIFY_ADD_DEVICE in device_add()
before device_initialize_trust() is called. Is bus_trust always 0 during
IOMMU probing for these non-PCI devices, disabling protections like SWIOTLB
bounce buffering?

[ ... ]

> @@ -30,18 +43,23 @@ static enum device_trust driver_trust(struct module *mod)
>   * policy on trusting devices it attaches, update the device's trust
>   * level from that policy. Trust privileges beyond driver bind are
>   * realized in a bus's ->dma_configure().
> + *
> + * Reflect the operational trust level back to the public indicator.
>   */
>  bool device_trust_bind(const struct device_driver *drv, struct device *dev)
>  {
>  	enum device_trust drv_trust = driver_trust(drv->owner);
>  
> -	if (drv_trust != DEVICE_TRUST_UNSET)
> +	if (drv_trust != DEVICE_TRUST_UNSET) {
>  		dev->p->trust = drv_trust;
> +		dev->bus_trust = drv_trust;
> +	}
>  	return dev->p->trust > DEVICE_TRUST_NONE;
>  }

[Severity: High]
Does overwriting dev->bus_trust with the driver's software trust level disable
dynamic IOMMU DMA protections?

When device_untrusted() evaluates dev->bus_trust after binding, it will
transition to false. Will this silently disable protections like SWIOTLB
bounce buffering in dev_use_swiotlb() for active untrusted devices?

Also, if an untrusted parent bridge (e.g., a Thunderbolt port) binds to the
pcieport driver, its bus_trust becomes AUTO. Will hot-plugged downstream
devices fail to inherit the untrusted state because pci_untrusted(parent)
evaluates to false in set_pcie_untrusted()?

[ ... ]

> diff --git a/include/linux/device.h b/include/linux/device.h
> index 7b2baffdd2f55..3e203d573a580 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -791,6 +793,7 @@ struct device {
>  	struct device_physical_location *physical_location;
>  
>  	enum device_removable	removable;
> +	enum device_trust	bus_trust;
>  
>  	DECLARE_BITMAP(flags, DEV_FLAG_COUNT);
>  };

[Severity: Low]
Is enum device_trust an incomplete type here?

Since <linux/device/trust.h> is not included in <linux/device.h>, does using
it as a value-type field cause a compilation error in files that don't include
<linux/device/trust.h> manually?

[ ... ]

> diff --git a/include/linux/device/trust.h b/include/linux/device/trust.h
> index 3377d26dc485d..283d3196e5e69 100644
> --- a/include/linux/device/trust.h
> +++ b/include/linux/device/trust.h
[ ... ]
>  #ifdef CONFIG_DEVICE_TRUST
> +bool device_untrusted(struct device *dev);
>  void module_driver_trust(struct module *mod, const char *val);
> -void module_driver_trust_init(struct module *mod, bool distrust);
> +void module_driver_trust_init(struct module *mod, bool require_trust);
>  #else
>  static inline void module_driver_trust(struct module *mod, const char *val)
>  {
>  	pr_warn("module: %s: trust= support disabled\n", mod->name);
>  }
> -static inline void module_driver_trust_init(struct module *mod, bool distrust)
> +static inline void module_driver_trust_init(struct module *mod, bool require_trust)
>  {
>  }
>  #endif

[Severity: Low]
Does this missing #else stub for device_untrusted() cause build failures?

Since CONFIG_DEVICE_TRUST is selected by PCI, configuring a kernel without PCI
but with IOMMU DMA support leaves device_untrusted() implicitly declared in
core IOMMU code like dev_use_swiotlb(). Should there be a fallback inline
function here?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260705220819.2472765-1-djbw@kernel.org?part=9