[PATCH 00/17] driver core: Authorize device trust before driver binding
From: Leon Romanovsky
Date: Thu Nov 05 2026 - 06:51:30 EST
Device trust was a concept introduced by Dan in his series here:
https://lore.kernel.org/all/20260705220819.2472765-1-djbw@xxxxxxxxxx
This series takes just the Device Trust idea and works to introduce
it aside from the other components.
Device Trust is a general concept that already exists in PCI via the
'untrusted' flag. This series generalizes that into a consistent
cross-bus concept that allow the user to inject their own opinion into
how the kernel should operate the device. Three levels are defined:
- DISABLED: Device is not operated by the kernel and is kept
quarantined. Confidential computing kernels will start all
devices in that mode.
- ADVERSARY: Device may be malicious and the kernel should defend
itself, eg by forcing use of a strong iommu, not exposing random
kernel memory to DMA and maybe even protections in the driver from
malicious data in DMAs.
- FULL: The normal kernel operating mode.
Aside from this basic idea of defining the three levels, this series
also introduces a mechanism for userspace to make a policy decision
which level the device should operate in.
This is important for Confidential Computing systems that need to
evaluate a device, do a cryptographic authentication, enable PCIe link
encryption, and other steps designed to protect the system. These
operations need to be done in userspace before any DMA access to the
device is allowed.
Using this series the user can boot the kernel with a default trust
policy of DISABLED, allowing only a small number of devices like
interrupt controllers, timers and iommus to start. Then the kernel can
get into the initrd where a userspace policy agent and implement
whatever decisions are required.
For Confidential Computing it is important that the policy logic be
robustly inclusive. If the kernel autoprobes any sort of real HW
device without going through the policy phase it could become an
attack vector.
Finally the policy agent can set the trust level and then cause a
driver to bind in the normal way. User control of driver binding was
already setup in 2007 via commit b8c5cec23d5c ("Driver core: udev
triggered device-<>driver binding") which relied on the
drivers_autoprobe to work.
At least for Confidential Computing a high security policy in
userspace would leave unexpected devices as DISABLED, authenticated
PCI devices as FULL and everything else ADVERSARIAL.
A draft starting point for a policy agent has been prepared:
https://github.com/rleon/systemd/commits/accept-d-trust-level
As a proposed systemd service that manages the process.
Thanks
Signed-off-by: Leon Romanovsky <leonro@xxxxxxxxxx>
---
Leon Romanovsky (17):
Input: gameport - attach manual drivers through the driver core
Input: serio - attach manual drivers through the driver core
net: phy: Attach generic PHY drivers through the driver core
wifi: mac80211_hwsim: lock device for manual driver binding
USB: Lock registered interfaces during manual driver binding
PNP: Attach card devices through the driver core
cdx: Propagate DMA configuration errors
driver core: Allow userspace to detect EPROBE_DEFER when using sysfs drivers_probe
driver core: Introduce a generic device trust level
driver core: Expose device trust authorization through sysfs
driver core: Accept device trust policy on the kernel command line
driver core: Accept device trust policy by driver name
driver core: Preserve trust commitment beyond driver binding
driver core: Add a global initial device trust policy
driver core: Cover trust authorization and binding with KUnit
driver core: Document trust admission and initrd authorization
PCI: Replace untrusted state with device trust
Documentation/ABI/testing/sysfs-bus-drivers-probe | 13 +
Documentation/ABI/testing/sysfs-devices-trust | 61 +
Documentation/admin-guide/kernel-parameters.txt | 64 +
.../driver-api/driver-model/device-trust.rst | 294 ++++
Documentation/driver-api/driver-model/index.rst | 1 +
MAINTAINERS | 2 +
drivers/base/Makefile | 2 +-
drivers/base/base.h | 37 +
drivers/base/bus.c | 9 +-
drivers/base/core.c | 18 +-
drivers/base/dd.c | 88 +-
drivers/base/test/Makefile | 1 +
drivers/base/test/device-trust-test.c | 1607 ++++++++++++++++++++
drivers/base/trust.c | 455 ++++++
drivers/bluetooth/btusb_main.c | 42 +-
drivers/cdx/cdx.c | 2 +-
drivers/input/gameport/gameport.c | 21 +-
drivers/input/serio/serio.c | 24 +-
drivers/iommu/amd/iommu.c | 3 +-
drivers/iommu/dma-iommu.c | 14 +-
drivers/iommu/intel/iommu.c | 17 +-
drivers/iommu/iommu.c | 17 +-
drivers/net/phy/phy_device.c | 39 +-
drivers/net/wireless/virtual/mac80211_hwsim_main.c | 2 +
drivers/pci/ats.c | 4 +-
drivers/pci/pci.c | 5 +-
drivers/pci/probe.c | 26 +-
drivers/pci/quirks.c | 7 +-
drivers/pnp/card.c | 12 +-
drivers/usb/core/driver.c | 30 +-
drivers/usb/core/message.c | 10 +
drivers/usb/core/usb.h | 2 +
include/linux/device.h | 16 +
include/linux/device/bus.h | 10 +
include/linux/device/trust.h | 48 +
include/linux/pci.h | 30 +-
36 files changed, 2886 insertions(+), 147 deletions(-)
---
base-commit: 6628e7d4c6b25c8d18f1345e3a20d21829aae7e4
change-id: 20260915-device-trust-core-12934e618489
Best regards,
--
Leon Romanovsky <leonro@xxxxxxxxxx>