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

[Jason Gunthorpe]

On Mon, Feb 23, 2026 at 11:11:23AM -0800, dan.j.williams@xxxxxxxxx wrote:
> Jonathan Cameron wrote:
> [..] 
> > From a simple case of 'what is here' in this set, the only bit I'm seeing
> > change in order to implement what I think you and Jason are describing is we
> > don't bother checking the cert chain in kernel for the first time: We
> > provide that to userspace to decide if it's good. If I understand
> > correctly, this will be at the end of the full sequence once we've pushed
> > through a nonce and gotten signatures + measurements.  Same as checking a
> > TSM provided transcript. That was sort of happening anyway if we consider
> > the .cma keyring as just providing a short cut filter if we didn't trust
> > the device provided root cert.
> > User space got the transcripts before it had to make any decision on
> > binding and could do anything it liked with them.
> 
> Exactly, the kernel checking the cert is not sufficient to establish
> trust in the device interface (Link + MMIO). If userspace is making a
> driver-bind or TDISP accept decision, it needs
> certs+measurements+interface-report and does not benefit from the kernel
> also validating the certificate.

Right, and from that position you have to ask *why* would the kernel
ever check the certs, what use case is that supporting, and I can't
come up with any beyond some kernel-internal simple verifier. So why
do we have a cma keyring at all?

I'm willing to be convinced there is some compelling embedded reason
why putting the verifier in the kernel instead of userspcae saves a
meaningful amount of flash - but I don't think we should start there
on the kernel side. First kernel steps should be to enable the
userspace verifier flow, which serves all use cases and offers the
highest policy flexibility.

Resume/RAS is handled by a much stronger same device check, not a weaker
kernel verifier with a root of trust in a keyring.

If somebody eventually wants a weaker check on resume then come with
that explanation and justification and lets talk about it later. I
would probably offer an eBPF policy hook not a CMA keyring though...

> > For that caching the public key bit, I'm not clear on whether you intend
> > to do that from kernel side (which I think I'd prefer) or have user space
> > squirt that key back in again?  If we are doing it in kernel we can
> > at least always verify the transcript is self consistent and refuse to
> > give anything to user space if it's not consistent (other than debug material).
> > By self consistent I mean we verify the signature against the device provided
> > cert (might as well verify whole chain as that's trivial given we have to partly
> > parse them anyway to find the cert).  I don't think it maters hugely if
> > we do this in kernel beyond advantage of removing a few foot guns and
> > simplifying the userpace interface to "I'm fine with the provided transcript
> > for use when I'm not here next time" write. Disadvantage is we use the
> > cert parsing code (which is there anyway) and parse it all twice - once
> > in kernel and probably again in userspace or at some remote verifier.
> 
> Right, the proposal is cache the public-key from pci_tsm_ops::connect()
> and at least require that the resulting transcript from that session
> establishment is properly self-signed. No point in continuing with a TSM
> implementation that is not self-consistent.

I don't have a strong feeling either way, but agree having the kernel
do it automatically and magically seems overall better if it is
possible.

What I want to achieve is a very strong robust 'same device check'
such that if the same device check passes then the userspace verifier
would accept the device again as nothing it could be sensitive to
would change.

As I said in the other email I expect the private keys to be unique to
the physical device so checking the leaf certificates is most of the
way to a same device check. You then need to confirm the FW
configuration of the device is identical.
 
> > Measurement verification (in kernel) is potentially a trickier bit of ABI
> > design as the space of what might be in there and what matters for a given
> > device is complex to say the least.  Only a small part of that is spec
> > defined.

Yes, I suggested we may have the device driver contribute this. From a
kernel perspective we can set out what 'same device check' means and
the drivers have to implement this by processing thier own device
specific attestation.

It is not the same as trying to do "measurement verificaiton" where
you may have a broad policy of what versions and configurations are
acceptable. Here we want simple "measurement has not changed", which I
think is reasonable to do in the kernel.

I gather these attestation reports are complex to parse so it would
make sense to do all that in rust...

> > I can see there may be some use cases where we relax things beyond this
> > (potentially including .cma keyring and root cert only)
> 
> So I expect there will be an extended tail of problems to solve from
> same device and same measurements checks, to full recovery into the TCB.
> A .cma keyring may be a part of that eventually, but the "as simple as
> possible, but no simpler" starting point is userspace device policy
> wrapped around self-signed evidence.

I'm also willing to entertain a cma keyring, but only with a strong
justification and fitting into this overall security model after we
establish the initial basic flows in their most secure versions.

> If the device interface is adversarial, mere trust in the SPDM session
> is insufficient to protect against the type of attacks that re-checking
> the certificate only after reset/resume is meant to mitigate.

Right, if you want to exclude physical attacks checking certificates
only is clearly not sufficient.

Jason