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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] A device's operational trust level (`dev->p->trust`) is persistently mutated before probe and not reverted on failure or unbind, leaking elevated privileges.
- [High] Providing an invalid `trust=` module parameter silently bypasses the restrictive module trust policy.
- [Low] The kernel fails to compile when CONFIG_DEVICE_TRUST is disabled due to an undeclared require_trust variable.
--

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

device core: Initial device trust infrastructure
    
Introduce a per-device trust concept. 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.
    
Link: http://lore.kernel.org/2026032621-astound-mounted-07a6@gregkh
Link: https://lwn.net/Articles/865918/

> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index 60c005223844d..f0b2d58c89a07 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -857,6 +857,11 @@ static int __driver_probe_device(const struct device_driver *drv, struct device
>  	dev_dbg(dev, "bus: '%s': %s: matched device with driver %s\n",
>  		drv->bus->name, __func__, drv->name);
>  
> +	if (!device_trust_bind(drv, dev)) {
> +		dev_dbg(dev, "not trusted to bind\n");
> +		return -ENODEV;
> +	}
> +

[Severity: High]
If really_probe() fails later in this function, or if the driver is unbound via
sysfs, does the device retain its newly elevated operational trust level?

When device_trust_bind() is called, it destructively overwrites dev->p->trust:

drivers/base/trust.c:device_trust_bind() {
        ...
        if (drv_trust != DEVICE_TRUST_UNSET)
                dev->p->trust = drv_trust;
        ...
}

Should there be a mechanism to rollback the device's trust level to its
baseline state on probe failure or driver unbind?

>  	pm_runtime_get_suppliers(dev);
>  	if (dev->parent)
>  		pm_runtime_get_sync(dev->parent);

> diff --git a/kernel/module/main.c b/kernel/module/main.c
> index 46dd8d25a6058..3e1fe9966d50b 100644
> --- a/kernel/module/main.c
> +++ b/kernel/module/main.c

[ ... ]

> @@ -3375,6 +3382,11 @@ static int unknown_module_param_cb(char *param, char *val, const char *modname,
>  		return 0;
>  	}
>  
> +	if (strcmp(param, "trust") == 0) {
> +		module_driver_trust(mod, val);
> +		return 0;
> +	}
> +

[Severity: High]
Can a malicious or unvetted driver bypass the explicit opt-in policy
(require_trust=1) by passing an invalid trust parameter?

If an unrecognized value like "trust=garbage" is passed, device_trust_parse()
returns DEVICE_TRUST_UNSET (0). module_driver_trust() will then overwrite
mod->trust with DEVICE_TRUST_UNSET.

Because this function unconditionally returns 0 (success) without checking for
invalid input, the module load succeeds. During probe, device_trust_bind()
ignores DEVICE_TRUST_UNSET and falls back to the device's existing trust level:

drivers/base/trust.c:device_trust_bind() {
        enum device_trust drv_trust = driver_trust(drv->owner);

        if (drv_trust != DEVICE_TRUST_UNSET)
                dev->p->trust = drv_trust;
        return dev->p->trust > DEVICE_TRUST_NONE;
}

This seems to erase the restrictive DEVICE_TRUST_NONE default policy and might
allow an unvetted driver to successfully attach. Should we return an error or
reject the load on invalid trust= values?

>  	/* Check for magic 'dyndbg' arg */
>  	ret = ddebug_dyndbg_module_param_cb(param, val, modname);

[ ... ]

> @@ -3544,6 +3556,7 @@ static int load_module(struct load_info *info, const char __user *uargs,
>  		goto bug_cleanup;
>  
>  	mod->async_probe_requested = async_probe;
> +	module_driver_trust_init(mod, require_trust);
>  

[Severity: Low]
Does this cause a build failure when CONFIG_DEVICE_TRUST is disabled?

The require_trust variable is declared inside an #ifdef CONFIG_DEVICE_TRUST
block earlier in this file, but it is passed unconditionally here. 

Since module_driver_trust_init() is defined as a static inline function in
include/linux/device/trust.h when the config is disabled, the compiler will
still evaluate its arguments, which would result in an undeclared variable
error.

>  	/* Module is ready to execute: parsing args may do that. */
>  	after_dashes = parse_args(mod->name, mod->args, mod->kp, mod->num_kp,

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