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

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

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.

And I know there are other types of devices that will want to use this
type of thing (i.e. SPDM seems to be spreading to other new bus types),
so it's good to have and get right.

thanks,

greg k-h