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

[dan.j.williams]

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.

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.