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

[Lukas Wunner <lukas@wunner.de>]

On Thu, Feb 19, 2026 at 01:39:37PM -0400, Jason Gunthorpe wrote:
> I'm arguing there are two very different steps here that must be kept
> separate. Verification is done when the device is first seen and the
> kernel is told it is OK to use the device.
> 
> A same-device check is performed if an already verified and accepted
> device resumes or RAS's in some way.
[...]
> Hence no keyring should be involved in resume.

No, that doesn't work.  You cannot rely on information that the device
presents.  The information may be spoofed.  The only secure way to
ascertain that the device you're talking to is what it purports to be
is to ask it for a signature and verify that the signature was made
with a device certificate which is signed by a root certificate
that you trust.  And the way to trust that root certificate is to
add it to a keyring.

There is no way around that.  What you have in mind could be achieved
by generating a secret token after first authentication and then using
that secret token after RAS / resume for re-authentication.  But I just
looked through the SPDM spec and it doesn't support that kind of thing.

A userspace verifier is incompatible with authentication after RAS
and resume.  It's a technical limitation that you'll have to live with,
I'm sorry.  If you could come up with, say, an eBPF verifier that
user space loads into the kernel, that might be a workable solution.

> I don't have an objection to an optional, useful for embedded, kernel
> side verifier that uses the cma ring.

Good.  My patches merely aim to be a spec-compliant implementation of
PCIe r7.0 sec 6.31 (Component Measurement and Authentication/SPDM).

That spec section does not talk about user space verifiers.

Moreover PCIe r6.1 page 115 states "CMA requires SPDM Version 1.0 or
above", so the baseline that we need to support for spec compliance
is the oldest spec version with the least features.  So even if a
future spec version introduced a feature to establish a shared secret
on first authentication and use that for subsequent authentication,
we'd still be constrained by the SPDM 1.0 feature set for compliance
with older devices.

> > > >   # 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
> 
> This is also not a very realistic scenario, there is no point to copy
> a certificate from a device into the cma key ring. If you want to
> trust the device as is without any verification then just accept it as
> is with a trivial userspace "verifier".

No, in the above example the device is not trusted "as is without any
verification".  The verification that happens above is a manual
comparison of the fingerprint with one provided by the vendor.

Thanks,

Lukas