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

[Robin Murphy <robin.murphy@arm.com>]

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.

Thanks,
Robin.