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

[Jonathan Cameron]

On Sat, 21 Feb 2026 15:29:55 -0800
dan.j.williams@xxxxxxxxx wrote:

> 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.  
> [..]
> > > 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.
> > 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.  I understand there are
> > features and authentication modes which are important for the
> > Confidential Computing world, but CoCo needs to fit into the
> > spec-defined mechanisms.  
> 
> The TDISP proposal from Jason and I bears repeating because it is a
> superset of what a CMA-only solution needs, and security guarantees it
> provides. I also submit that "identity revalidation over reset/resume"
> is not a *primary* concern. It is certainly *a* concern that needs to be
> part of the ongoing discussion to avoid painting ourselves into a
> corner, but certainly a complexity that is incremental to the base
> enabling. Recall CMA is only a building block to trusting the rest of
> the device interface outside of the SPDM session.
> 
> Userspace is in charge of all trust and verification decisions. A TSM
> driver, whether that driver is in-kernel-SPDM-library, or platform TSM,
> establishes a session with a device with a given certificate slot. The
> session establishment makes cert-chain+transcript available to userspace
> and caches the public-key. If userspace does not like that result, it
> opts to not bind a driver to that device, or retries with a different
> cert slot.
> 
> If later we want to support a "same device" capability in scenarios
> where a userspace round trip is infeasible then that is incremental ABI.
> That ABI would allow userspace to cache golden cert-chain+measurements.
> The resume path can revalidate that identity description with a fresh
> nonce and the cached public key.

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.

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.

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.

I can see there may be some use cases where we relax things beyond this
(potentially including .cma keyring and root cert only)

Jonathan


> 
> For TDISP the violence of dropping the device out of the TCB likely
> needs more sophistication than golden measurement revalidation. For CMA
> mere trust in the root cert is not sufficient for many of the
> adversarial device threat models, so the kernel need not carry that
> responsibility.
> 
> Aneesh and I are putting together some POC patches along these lines.
> 
>