From: Leon Romanovsky <leon@kernel.org>
To: sashiko-reviews@lists.linux.dev
Cc: linux-input@vger.kernel.org, linux-usb@vger.kernel.org,
linux-pci@vger.kernel.org, dmitry.torokhov@gmail.com
Subject: Re: [PATCH v2 11/19] driver core: Introduce a generic device trust level
Date: Tue, 10 Nov 2026 17:12:24 +0200 [thread overview]
Message-ID: <20261110151224.GM8635@unreal> (raw)
In-Reply-To: <sashiko-outbox-206511@kernel.org>
On Tue, Nov 10, 2026 at 07:35:20AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential
> issues to consider:
> - [High] driver core: device_trust_prepare_full() breaks default boots
> with -EPERM
> - [Medium] driver core: device_trust_prepare_full() calls
> trust_resolve() unlocked
> --
>
> commit cc9d85465ea19f97fc7a0889f6993f37d1a58048
> Author: Leon Romanovsky <leon@kernel.org>
>
> driver core: Introduce a generic device trust level
>
> This commit adds generic device trust admission and a device_trust.default
> boot parameter to resolve a device's trust policy into an active trust
> level before driver probing.
>
> > diff --git a/drivers/base/trust.c b/drivers/base/trust.c
> > new file mode 100644
> > index 0000000000000..6a71abf10b3bb
> > --- /dev/null
> > +++ b/drivers/base/trust.c
> > @@ -0,0 +1,132 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +
> > +#include <linux/device.h>
> > +#include <linux/errno.h>
> > +#include <linux/export.h>
> > +#include <linux/init.h>
> > +#include <linux/string.h>
> > +#include <kunit/visibility.h>
> > +
> > +#include "base.h"
> > +
> > +static enum device_trust_policy device_trust_default_policy __ro_after_init;
>
> [ ... ]
>
> > +static int __device_trust_prepare(struct device *dev,
> > + const struct device_driver *drv, bool full_only)
> > +{
> > + enum device_trust_policy policy;
> > + enum device_trust_level level;
> > + int ret;
> > +
> > + policy = dev->trust_policy;
> > +
> > + if (policy == DEVICE_TRUST_POLICY_DISABLED)
> > + return -EPERM;
> > + if (dev->bus && dev->bus->trust_resolve) {
> > + ret = dev->bus->trust_resolve(dev, drv, policy, &level);
> > + if (ret)
> > + return ret;
> > + } else {
> > + level = policy == DEVICE_TRUST_POLICY_ADVERSARY ?
> > + DEVICE_TRUST_ADVERSARY : DEVICE_TRUST_FULL;
> > + }
> > + if (level == DEVICE_TRUST_DISABLED)
> > + return -EPERM;
> > + if (full_only && level != DEVICE_TRUST_FULL)
> > + return -EPERM;
> > + if (dev->p->trust_state == DEVICE_TRUST_COMMITTED &&
> > + dev->trust_committed_level != level)
> > + return -EINVAL;
> > +
> > + WRITE_ONCE(dev->trust_committed_level, level);
> > + dev->p->trust_state = DEVICE_TRUST_COMMITTED;
> > + WRITE_ONCE(dev->trust_level, level);
> > + return 0;
> > +}
> > +
> > +int device_trust_prepare(struct device *dev, const struct device_driver *drv)
> > +{
> > + device_lock_assert(dev);
> > + return __device_trust_prepare(dev, drv, false);
> > +}
> > +
> > +int device_trust_prepare_full(struct device *dev, const struct device_driver *drv)
> > +{
> > + if (device_trust_default_policy != DEVICE_TRUST_POLICY_FULL)
> > + return -EPERM;
>
> [Severity: High]
> Does requiring device_trust_default_policy == DEVICE_TRUST_POLICY_FULL
> here cause device_driver_attach_full() to fail with -EPERM on every
> default boot where device_trust.default= is not passed on the command
> line?
>
> When device_trust.default= is omitted, device_trust_default_policy remains
> DEVICE_TRUST_POLICY_DEFAULT, even though that policy resolves to
> DEVICE_TRUST_FULL on buses without trust_resolve. Callers converted to
> device_driver_attach_full(), such as phy_attach_direct() when attaching
> the generic PHY fallback driver and serio_bind_driver(), will then fail
> with -EPERM unless the kernel is booted with device_trust.default=full.
While I did this intentionally to make sure that missing option won't
leave system unprotected, I had second thought now as it will break
backward compatibility.
>
> > +
> > + return __device_trust_prepare(dev, drv, true);
> > +}
>
> [Severity: Medium]
> Can device_trust_prepare_full() end up calling dev->bus->trust_resolve()
> without holding the device lock?
Not for the upstream code, both serio and PHY are connected to the
buses without ->trust_resolve().
Thanks
>
> The kernel-doc for struct bus_type::trust_resolve requires the device lock
> to be held, and the kernel-doc for device_driver_attach_full() states that
> buses with a trust resolver must use device_driver_attach(). Unlike
> device_bind_driver(), which rejects dev->bus->trust_resolve with
> -EOPNOTSUPP, device_trust_prepare_full() calls __device_trust_prepare()
> unlocked without checking dev->bus->trust_resolve.
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20261109-device-trust-core-v2-0-3b12d9a9f861@nvidia.com?part=11
>
next prev parent reply other threads:[~2026-11-10 15:12 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-09 7:33 [PATCH v2 00/19] driver core: Authorize device trust before driver binding Leon Romanovsky
2026-11-09 7:33 ` [PATCH v2 01/19] Input: gameport - attach manual drivers through the driver core Leon Romanovsky
2026-11-09 7:33 ` [PATCH v2 02/19] wifi: mac80211_hwsim: lock device for manual driver binding Leon Romanovsky
2026-11-09 7:33 ` [PATCH v2 03/19] USB: Lock registered interfaces during " Leon Romanovsky
2026-11-10 7:35 ` sashiko-bot
2026-11-10 14:19 ` Leon Romanovsky
2026-11-09 7:33 ` [PATCH v2 04/19] USB: Release interface claims refused during registration Leon Romanovsky
2026-11-10 7:35 ` sashiko-bot
2026-11-10 14:23 ` Leon Romanovsky
2026-11-09 7:33 ` [PATCH v2 05/19] PNP: Attach card devices through the driver core Leon Romanovsky
2026-11-09 7:33 ` [PATCH v2 06/19] cdx: Propagate DMA configuration errors Leon Romanovsky
2026-11-09 7:33 ` [PATCH v2 07/19] driver core: Report deferred probes through sysfs drivers_probe Leon Romanovsky
2026-11-09 7:33 ` [PATCH v2 08/19] driver core: Add a compatibility API for manual driver attachment Leon Romanovsky
2026-11-09 7:33 ` [PATCH v2 09/19] Input: serio - use the compatibility driver attachment API Leon Romanovsky
2026-11-10 7:35 ` sashiko-bot
2026-11-10 14:29 ` Leon Romanovsky
2026-11-09 7:33 ` [PATCH v2 10/19] net: phy: Use " Leon Romanovsky
2026-11-09 13:45 ` Andrew Lunn
2026-11-10 7:39 ` Leon Romanovsky
2026-11-10 14:31 ` Andrew Lunn
2026-11-10 14:58 ` Leon Romanovsky
2026-11-10 7:35 ` sashiko-bot
2026-11-09 7:33 ` [PATCH v2 11/19] driver core: Introduce a generic device trust level Leon Romanovsky
2026-11-10 7:35 ` sashiko-bot
2026-11-10 15:12 ` Leon Romanovsky [this message]
2026-11-09 7:33 ` [PATCH v2 12/19] driver core: Expose device trust authorization interfaces Leon Romanovsky
2026-11-09 7:33 ` [PATCH v2 13/19] driver core: Accept device trust policy on the kernel command line Leon Romanovsky
2026-11-09 7:33 ` [PATCH v2 14/19] driver core: Accept device trust policy by driver name Leon Romanovsky
2026-11-10 7:35 ` sashiko-bot
2026-11-09 7:33 ` [PATCH v2 15/19] driver core: Expose committed device trust level Leon Romanovsky
2026-11-09 7:33 ` [PATCH v2 16/19] driver core: Cover trust authorization and binding with KUnit Leon Romanovsky
2026-11-10 7:35 ` sashiko-bot
2026-11-09 7:33 ` [PATCH v2 17/19] driver core: Document trust admission and initrd authorization Leon Romanovsky
2026-11-09 7:33 ` [PATCH v2 18/19] PCI: Replace untrusted state with device trust Leon Romanovsky
2026-11-09 13:53 ` Robin Murphy
2026-11-10 12:22 ` Leon Romanovsky
2026-11-10 14:25 ` Jason Gunthorpe
2026-11-10 14:34 ` Leon Romanovsky
2026-11-10 7:35 ` sashiko-bot
2026-11-09 7:33 ` [PATCH v2 19/19] USB: Authorize devices and interfaces through " Leon Romanovsky
2026-11-10 7:35 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261110151224.GM8635@unreal \
--to=leon@kernel.org \
--cc=dmitry.torokhov@gmail.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox