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

[Leon Romanovsky <leon@kernel.org>]

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