Re: [RFC v3 00/27] lib: Rust implementation of SPDM

[Greg KH <gregkh@linuxfoundation.org>]

On Thu, Feb 19, 2026 at 03:15:34PM +0100, Lukas Wunner wrote:
> On Thu, Feb 19, 2026 at 08:41:19AM -0400, Jason Gunthorpe wrote:
> > > It has turned out to be super convenient to expose the 8 slots with
> > > certificate chains in sysfs for direct examination with openssl and
> > > similar tools, without having to go through netlink.
> > 
> > Honestly, I'm reluctant to add permanent sysfs uAPI just for temporary
> > debugging. Put it in debugfs.
> 
> Exposure of the certificates in the SPDM slots is not for debugging,
> it's just super convenient for day-to-day use.
> 
> > Having to find/remember some baroque openssl command line with a
> > million options is not reasonable for a production kind of
> > environment.
> 
> Personally I find something like the following neither baroque nor
> unreasonable:
> 
>   # What's the certificate chain in slot0?
>   openssl storeutl -text /sys/bus/pci/devices/0000:03:00.0/certificates/slot0
> 
>   # Fingerprint of root cert in slot0, does it match what vendor claims?
>   openssl x509 -fingerprint -in /sys/bus/pci/devices/0000:03:00.0/certificates/slot0
> 
>   # Looks good, let's trust it:
>   keyctl padd asymmetric "" %:.cma < /sys/bus/pci/devices/0000:03:00.0/certificates/slot0

As much fun as it is to abuse sysfs, please, let's not do this there.
You just did something that could have changed the device between
storing, checking and then trusting it as the device is never guaranteed
to remain the same across multiple calls to sysfs (i.e. yanked out and
another added.)

So let's not design in a security issue from the start please :)

thanks,

greg k-h