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

[Greg KH]

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
> > 
> > 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.)
> 
> No, the kernel caches the certificate chains read from the SPDM slots
> and what is exposed in sysfs is that cached copy.  So all three commands
> above pertain to the same certificate chain.

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.

> > So let's not design in a security issue from the start please :)
> 
> The alleged security issue does not exist.

How is this not the classic definition of a TOCTOU (time-of-check to
time-of-use) problem?

thanks,

greg k-h