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

[Jason Gunthorpe <jgg@nvidia.com>]

On Sat, Feb 21, 2026 at 07:46:09PM +0100, Lukas Wunner wrote:
> On Fri, Feb 20, 2026 at 10:10:57AM -0400, Jason Gunthorpe wrote:
> > 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.
> 
> What you seem to have in mind is essentially a "trust on first use"
> model where trust is given to a specific device certificate
> (i.e. leaf certificate), not to a root certificate.

Not really, please read my email again.

I said userspace does the verification, using all the certificate
chains and beyond. Then once verified the kernel only does a 'same
device' check that ensures the device hasn't changed from what was
originally verified.

Spec supports this just fine.

> certificates.  These could be vendors, but it's also possible that
> e.g. a CSP operates its own CA and provisions one of the 8 slots with
> a custom certificate chain anchored in its own CA.

And the userspace verifier is free to check all of this.

> An alternative solution would be to have the verifier in user space
> operate its own mini CA.  The root certificate of that mini CA would be
> added to the .cma keyring.  

No! Why are you trying to massively over complicate this? The proposal
is very simple :(

> > 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?
> 
> There are products out there which support CMA but not TDISP.

Sure, but that doesn't mean anything for verification.

Most models I've seen for using this stuff are "cloud connected"
things where the cloud is going to measure and attest the end device
before giving it anything sensitive.

That's remote verification, and what you absolutely don't want is some
way for the attacker to pass remote verification, then replace the
device and somehow pass a much weaker local only verification and
attack the security.

This is why I'm insistent the starting point for resmue is a very
strong same-device check that prevents attackers from replacing the
device with something that wouldn't pass remote verification.

If you don't do this and instead try to revalidate the certificate
chains the kernel can be tricked into accepting a different device on
resume and that will completely destroy the entire security model.

> In other words, the CC world isn't everything.  The modest goal
> of this series is to allow authentication of devices in compliance
> with PCIe r7.0 sec 6.31 and the SPDM spec.  

As Dan and I keep saying you should focus on enabling userspace
verifier as the very first modest step and then come with proposals to
add additional things like resume and perhaps a kernel-internal
verifier.

I don't see a role for a cma keyring outside a kernel-internel
verifier (and I'm skeptical this is desirable in the first place since
a userspace implementation would not be such a burden)

Jason