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

[Jason Gunthorpe <jgg@nvidia.com>]

On Tue, Feb 24, 2026 at 04:54:15PM +0100, Lukas Wunner wrote:
> On Tue, Feb 24, 2026 at 10:16:10AM -0400, Jason Gunthorpe wrote:
> > 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.
> 
> Finding a different device on resume is par for the course for hotplug.

And? The point is we must detect and reject this as a matter of
security.
 
> > 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.
> 
> There is nothing to "add".  Seamless re-verification on resume and
> error recovery is already implemented in my patches.  I don't see
> the point of throwing that out the window and start from scratch
> just because you think it doesn't have priority.

The objection is it doesn't implement a sufficient security model, and
I'm strongly arguing you have built the wrong thing.

The suggested path is not about priority, but to follow the path of
consense where we all agree a userspace verifier is a required
component, so we should start with the parts we all agree on and
incrementally work on the dis-agreed parts.

Saying I already built it so I should get to merge it is not
constructive.

> I'm coming from a very different direction, I want this to seamlessly
> integrate with all the infrastructure we already have in the PCI core
> (hotplug, suspend/resume, error recovery, ...), so I made sure it does.

Well, this is security work. Linking a bunch of stuff together without
having a clear threat model and desired seurity properties is not the
right approach at all.

The kernel needs to enforce security properties and present a
consistent threat model, and what you have done is inconsisent and
weaker than the models we do want to build.

It also seems all your use cases fit within the broder models, so I
don't see why we should enshrine a bad security model in the kernel,
as UAPI at this point.
 
> I don't share the view that CMA is merely a building block for TDISP.
> It's useful on its own.

I agree it is useful on its own, but when used without TDISP we still
want to have the same basic threat model and overall security posture,
it is not an excusse to just weaken everything.

We are looking at building CMA based, non-TDISP systems that need all
the stuff I'm talking about.

> I also believe that the vast majority of users will simply need this
> to ensure the devices they attach to their chromebooks, phones etc
> are authentic (seems important given the reports of counterfeit
> hard drives).  A .cma keyring is good enough for Grandma's chromebook,
> no need for a user space verifier.

A chromebook has no issue to run a userspace verifier, and overall the
kernel community prefers to put things to userspace whenever possible.

Given a userspace solution will have to exist I think you have a
fairly high bar to cross to propose duplicating it into the kernel,
which is why it should come after the userspace path is setup so it
can be properly explained and justified.

Jason