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

[Greg KH]

On Fri, Feb 20, 2026 at 12:45:19PM +0100, Lukas Wunner wrote:
> On Fri, Feb 20, 2026 at 10:14:56AM +0100, Greg KH wrote:
> > On Fri, Feb 20, 2026 at 08:46:21AM +0100, Lukas Wunner wrote:
> > > On Thu, Feb 19, 2026 at 03:40:25PM +0100, Greg KH wrote:
> > > > On Thu, Feb 19, 2026 at 03:15:34PM +0100, Lukas Wunner wrote:
> > > > >   # 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
> > > > 
> > So if a device is removed and a different one added between steps 2 and
> > three above, with the same pci number, all is ok?
> > 
> > Remember, PCI device ids are not unique, they can come and go and be
> > reordered and reused at any point in time.  They are fully dynamic and
> > should NEVER be used as a unique identifier except for a specific moment
> > in time.
> > 
> > In other words, you are expecting that device id to always refer to the
> > same device across all 3 operations, which is never guaranteed.
> 
> If the user chooses to replace the device between steps 2 and 3,
> they get to keep the pieces.

So you are saying that is ok to do:
   - test if we trust the fingerprint
   - trust the device of a fingerprint we didn't check

Then why do step 1 here at all?

Perhaps sysfs just isn't the best api here :)

thanks,

greg k-h