Re: [PATCH 10/17] driver core: Expose device trust authorization through sysfs

[Leon Romanovsky <leon@kernel.org>]

On Thu, Nov 05, 2026 at 09:03:11AM -0500, Greg Kroah-Hartman wrote:
> On Thu, Nov 05, 2026 at 01:59:20PM +0000, Robin Murphy wrote:
> > On 2026-11-05 1:40 pm, Greg Kroah-Hartman wrote:
> > > On Thu, Nov 05, 2026 at 03:27:29PM +0200, Leon Romanovsky wrote:
> > > > On Thu, Nov 05, 2026 at 08:10:14AM -0500, Greg Kroah-Hartman wrote:
> > > > > On Thu, Nov 05, 2026 at 01:42:23PM +0200, Leon Romanovsky wrote:
> > > > > > From: Leon Romanovsky <leonro@nvidia.com>
> > > > > > 
> > > > > > An initrd must authorize a disabled device after attestation even if a
> > > > > > built-in driver already attempted to probe it.
> > > > > > 
> > > > > > Expose requested trust_policy and read-only active trust. Allow explicit
> > > > > > disabled policy to advance once to adversary or full, fixing that decision
> > > > > > immediately. Reject later policy changes, including for a device claimed
> > > > > > before registration, while allowing same-value writes on live devices.
> > > > > > Keep initial unrestricted selection separate from explicit authorization
> > > > > > and bind-time commitment. Serialize writes with probing under the device
> > > > > > lock. Include the attributes in device ownership changes.
> > > > > > 
> > > > > > Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
> > > > > > ---
> > > > > >   Documentation/ABI/testing/sysfs-devices-trust |  51 +++++++++++++
> > > > > >   MAINTAINERS                                   |   1 +
> > > > > >   drivers/base/base.h                           |   6 ++
> > > > > >   drivers/base/core.c                           |  15 +++-
> > > > > >   drivers/base/trust.c                          | 102 ++++++++++++++++++++++++++
> > > > > >   5 files changed, 174 insertions(+), 1 deletion(-)
> > > > > > 
> > > > > > diff --git a/Documentation/ABI/testing/sysfs-devices-trust b/Documentation/ABI/testing/sysfs-devices-trust
> > > > > > new file mode 100644
> > > > > > index 0000000000000..97e07a174769c
> > > > > > --- /dev/null
> > > > > > +++ b/Documentation/ABI/testing/sysfs-devices-trust
> > > > > > @@ -0,0 +1,51 @@
> > > > > > +What:		/sys/devices/.../trust
> > > > > > +Date:		September 2026
> > > > > > +Contact:	driver-core@lists.linux.dev
> > > > > > +Description:
> > > > > > +		(RO) The active trust level for the device. The values are
> > > > > > +		"disabled", "adversary", and "full". Driver core resolves
> > > > > > +		the level before DMA configuration and probe, and retains it
> > > > > > +		through removal and DMA cleanup. Outside a bind transaction
> > > > > > +		the level is "disabled". This does not imply that policy is
> > > > > > +		writable or that the device has never operated.
> > > > > > +
> > > > > > +What:		/sys/devices/.../trust_policy
> > > > > > +Date:		September 2026
> > > > > > +Contact:	driver-core@lists.linux.dev
> > > > > > +Description:
> > > > > > +		(RW) The requested trust policy for the device. The initial
> > > > > > +		value may be selected by the bus before the device is
> > > > > > +		registered; otherwise it is "default". The policy is resolved
> > > > > > +		to an active trust level before the device is probed.
> > > > > > +
> > > > > > +		The values are "default", "disabled", "adversary", and
> > > > > > +		"full". "default" lets the bus select the active trust level.
> > > > > > +		"disabled" prevents a functional driver from binding.
> > > > > > +		"adversary" requests operation with the restrictions that the
> > > > > > +		bus and DMA layers can enforce for a potentially malicious
> > > > > > +		device; it does not isolate DMA by itself. "full" requests
> > > > > > +		normal operation.
> > > > > > +
> > > > > > +		Before an operating level is committed, policy may change
> > > > > > +		freely until "disabled" is selected. Explicit "disabled"
> > > > > > +		blocks binding while allowing a later write of "adversary" or
> > > > > > +		"full". Repeated rejected probes preserve this opportunity.
> > > > > > +		Authorization immediately fixes the requested policy.
> > > > > > +		Returning to "default" or "disabled", or selecting another
> > > > > > +		mode, fails.
> > > > > > +
> > > > > > +		Successful resolution to an allowed level commits policy
> > > > > > +		and operating level before driver or DMA setup. Both remain
> > > > > > +		fixed for the device object's lifetime, including through
> > > > > > +		failed or deferred probes, unbind, reset, and driver reload.
> > > > > > +		Later binds must resolve to the same level, including when
> > > > > > +		the policy is "default". A resolver error or disabled result
> > > > > > +		before commitment leaves the policy's writability unchanged.
> > > > > 
> > > > > I understand you are aproaching this from a PCI point-of-view, but many
> > > > > busses do not care or have DMA at all, and need to actually talk to the
> > > > > device before being able to even "add" it to the kernel.  So you are
> > > > > making a driver core-specific policy based on mentioning DMA here, when
> > > > > really that should only be a bus-specific thing, right?  Some busses
> > > > > might require DMA to happen (i.e. USB needs their host controllers to
> > > > > use DMA to even talk to the device at all).
> > > > > 
> > > > > So can this be written to be more vague and generic and then put the
> > > > > specifics in the bus-specific portion?
> > > > 
> > > > Yes, of course. The main point is that drivers must not communicate with
> > > > or configure hardware before attestation is approved. DMA is the PCI
> > > > way to communicate with hardware.
> > > 
> > > That's a very vague statement of "must not communicate with".  Busses
> > > HAVE to talk to the device to determine what the device even is before
> > > it can add it to its internal bus list.  That's just how the hardware
> > > works, you can't say "no talking at all" otherwise that means that you
> > > never even know if a device is there (and for some busses, you'll miss
> > > the device entirely as they can only be found when the "host controller"
> > > tells the kernel that a device showed up, not later by manually
> > > scanning.)
> > > 
> > > Think about reading PCI device ids, or USB configuration information,
> > > that's a bus-core thing.  Are you really thinking that non of this can
> > > be read from a device under this "policy"?
> > 
> > Yup, and that's true even in the PCI TDISP case - there's a major amount of
> > "communication" and "configuration" involved in that. The principle which
> > should (hopefully) generalise is that a bus/host controller driver can
> > always interrogate its child device to perform whatever attestation and
> > general configuration is appropriate, but we won't hand off any _control_ of
> > that device to a specific device driver (nor enable potentially-impactful
> > bus-level features like DMA, interrupts, etc. if relevant) without the
> > requisite agreement between the bus code and the user.
> 
> I agree, that's fine, the bus core should always be able to talk to the
> device, the "barrier" is where the device is handed to a driver for that
> bus.  That's what I'm trying to say here, DMA is often needed before
> that can ever happen, so no claims of "no dma is happening" should be
> here.

You wanted vague terminology, I was vague :)
Anyway, Robin perfectly described the trust model we are trying to implement here.

Thanks

> 
> thanks,
> 
> greg k-h