Re: [PATCH 17/17] PCI: Replace untrusted state with device trust

[Leon Romanovsky <leon@kernel.org>]

On Thu, Nov 05, 2026 at 10:43:00AM -0500, Greg Kroah-Hartman wrote:
> On Thu, Nov 05, 2026 at 10:03:52AM -0400, Jason Gunthorpe wrote:
> > On Thu, Nov 05, 2026 at 03:18:56PM +0200, Leon Romanovsky wrote:
> > > On Thu, Nov 05, 2026 at 08:12:51AM -0500, Greg Kroah-Hartman wrote:
> > > > On Thu, Nov 05, 2026 at 01:42:30PM +0200, Leon Romanovsky wrote:
> > > > > From: Leon Romanovsky <leonro@nvidia.com>
> > > > > 
> > > > > Convert the PCI specific untrusted to use the common device trust
> > > > > level. Adversarial means the same thing untrusted does.
> > > > 
> > > > What about for USB?  Will that "move" to use this common trust level?
> > > > If not, I don't think it's very "common" :)
> > > 
> > > It supposed to work for all buses out-of-the box, at least this is the
> > > intention.
> > 
> > You mean DISABLED/FULL should work with this patch series on USB
> > right? Meaning the core code will not bind a USB driver when DISABLED?
> > 
> > I was wondering if some of the broader things we are doing on PCIe
> > also apply to USB, like device authentication. I don't know alot about
> > USB, but I got AI to help me find some relavent spec information.
> > 
> >  https://usb.org/authentication
> > 
> > This looks like the parallel to PCIe SPDM device authentication. I
> > would expect it to work broadly the same way as PCIe if anyone wanted
> > to implement it:
> 
> No real need to as no one actually made a USB device with that spec :)
> 
> There was some patches on the linux-usb list 6 months or so ago to try
> to implement it, but it stalled due to there not even be any devices to
> test it for.
> 
> > 1) USB discovery discovers authentication support and creates an
> >    attestation subsystem device for it
> > 2) The struct device starts up with trust = DISABLED
> > 3) Userspace runs the crypto flow through attestation subsystem. This
> >    is extremely similar looking to PCIe SPDM:
> >     1. GET_DIGESTS -> device returns a hash for each certificate chain
> >        slot it has.
> >     2. GET_CERTIFICATE -> device returns its certificate chain, read
> >        in pieces.
> >     3. CHALLENGE (nonce) -> device returns CHALLENGE_AUTH: the chain
> >        hash, a salt, a hash of its descriptors, and a signature over the
> >        challenge and the response.
> > 4) Userspace inspects the above and approves the device
> > 5) trust = FULL, driver is probed.
> > 
> > But I supposed Greg is asking about /sys/bus/usb/devices/DEVICE/authorized ..
> 
> Yes, that is exactly what I am asking about.

I used AI assistance to create the conversion, which produced two patches.
The first exports `device_trust_set_policy()` to support
`/sys/,,,/authorized` and `/sys/.../interface_authorized_default`.
The second adds calls to the `device_trust_*()` functions.

https://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git/commit/?h=device-trust-core-v2&id=98f5d11580d736a7878323dfb7238cd08c6c76af
https://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git/commit/?h=device-trust-core-v2&id=f10f8e448540982699438dce369fef6cbfabcba5

Thanks