Re: [PATCH 10/17] driver core: Expose device trust authorization through sysfs
From: Robin Murphy
Date: Thu Nov 05 2026 - 08:49:56 EST
On 2026-11-05 1:27 pm, 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@xxxxxxxxxx>
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@xxxxxxxxxx>
---
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@xxxxxxxxxxxxxxx
+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@xxxxxxxxxxxxxxx
+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.
Indeed the principle of "I trust that this device is what it claims to be" should be universal, and that's really the thing we should represent here, it's just that most existing buses (especially simpler lower-level ones like I2C/SPI/etc.) are unlikely to ever have any kind of mechanism to be able to usefully attest that.
DMA is simply the biggest and most prominent attack surface for malicious devices, as it gives them the means to attempt to access arbitrary addresses; however even a non-DMA-capable device is still potentially capable of maliciously doing the "wrong" thing with data that a kernel driver explicitly gives it - imagine something pretending to be a USB network adapter that's actually clever enough to MITM your data at the packet level...
Thanks,
Robin.