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

From: Leon Romanovsky

Date: Thu Nov 05 2026 - 14:12:23 EST


On Thu, Nov 05, 2026 at 01:02:03PM -0400, Jason Gunthorpe wrote:
> On Thu, Nov 05, 2026 at 01:42:23PM +0200, Leon Romanovsky wrote:
> > + (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.
>
> For making this more general:
>
> "disabled" prevents a driver from binding and informs the kernel to
> provide containment of the device. For example a PCIe device should be
> unable to DMA to memory.
>
> > + "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.
>
>
> "adversary" informs the kernel that the userspace wants to opt into
> any security defenses the kernel may have to restrict and further
> validate interactions with the device. This may have a performance or
> functional cost compared to "full". As an example the DMA API and
> IOMMU layers will avoid exposing unrelated nearby memory to the device
> during DMA.
>
> > + Successful resolution to an allowed level commits policy
> > + and operating level before driver or DMA setup. Both remain
>
> "before driver startup"
>
> > + 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.
>
> Not sure what "resolver error" is.

The bus can provide custom logic for handling default policies through the
->trust_resolve() callback. This is "resolver".

Thanks

>
> Jason