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

[Jason Gunthorpe]

On Fri, Feb 20, 2026 at 09:30:50AM +0100, Lukas Wunner wrote:
> 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.

Yes, and in the most general case the nonce/etc for this must come
through userspace from an external verifier agent.

>  And the way to trust that root certificate is to
> add it to a keyring.

Not quite, the way to have a *kernel verifier* is to have a kernel
verifier use the cma keyring in this way. If you use a userspace
verifier the kernel keyring has no role.

> 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.

The kernel just records the information the device presented and
checks it is the same. Yes on the same-device check it will have to
make a new nonce and push it through, but it is only checking the
results against the previously cached information for this device, not
a general keyring.

> 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.

You are ignoring the proposal - the idea is to NOT VERIFY on resume,
but to only do a same-device check.

A same-device check should have no policy components that require a
verifier. It gives the device a new fresh nonce, obtains a new
signature, checks the signature works with the previously cached
public key(s).

IOW the resume/RAS acceptance criteria is that the second nonce was
signed with the same private key(s) that the first nonce was signed
with.

In many devices this will be entirely sufficient. It should be common
that each physical device has a unique private key with a certificate
chain to the manufactures secured certificate. Since the private key
is globally unique proving the device has it during resume is the
majority of a same-device check.

>From there the kernel can do additional checks, sanity check the
presented certificate list is exactly the same, check the attestation
report hasn't changed to ensure the device hasn't been replaced with
an insecure dowrev or something. (possibly the driver will have to
provide some helper to same-device check its attestation report)

No need for spec changes, no need for a key ring, very different flow
from verification.

The kernel should simply monitor the signature requests from the
verifier, internally confirm the reply is correct and record all the
public keys that were successfully used on this struct device.

> That spec section does not talk about user space verifiers.

Linux will have its own sw model, the spec is just the protocol
definition. In the CC world everyone just knows the verifier needs to
be external.. How else could it even work?

> > 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.

"manual comparision" is some debugging flow, like I pointed out at the
start.

Jason