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

[Jason Gunthorpe]

On Wed, Feb 18, 2026 at 09:05:28PM -0800, dan.j.williams@xxxxxxxxx wrote:
> Jason Gunthorpe wrote:
> > On Wed, Feb 18, 2026 at 03:40:10PM -0800, dan.j.williams@xxxxxxxxx wrote:
> > 
> > > So one proposal to get the x509 pre-work upstream is to extend the TSM
> > > core (drivers/pci/tsm.c) to export the certificates in sysfs, and update
> > > the existing "authenticated" attribute to reflect the result of cert
> > > chain validation.
> > 
> > Why do we want the validate the cert chain in the kernel? That sounds
> > like something the verifier should do?
> 
> This is more for the CMA case where Lukas was imagining automatic
> revalidation of device certificates coming out of resume before
> userspace is present. If someone wanted to use a TSM for device-auth +
> link encryption outside of TDISP and Confidential VMs, then it could use
> the same mechanism.

I think we should have one flow for this based on what we talked about
for TDSIP.

We are thinking about many interesting models, and some of them
include running an external verifier on this no-VM case well. Kernel
auto acceptance is not desirable for the same reasons it is not
desirable in a TVM.

If we do some automatic re-accept for RAS/resume it should be strongly
tied to some target pre-set by the userspace acceptance process - ie
"the device must present exactly this specific cert chain and nothing
else", and probably more too since we may want to exclude swapping out
device FW versions or similar.

Not sure how that fits into an sysfs file.

> > And not sure we should be dumping any certs in sysfs if the plan for
> > the other stuff is netlink, it should be consistent I think.
> 
> Lukas was only putting the dynamic / transactional pieces in netlink.
> Specifically device signature events (multicast) and device measurement
> collection with a nonce.
> 
> The static cert chain blobs can certainly also be in netlink... but no
> real driving need like there was for the other flows. I am also
> encouraged by Lukas's work to handle large blobs over netlink [1], but
> no real need to add that as a dependency to this simple mission of "just
> enough of a real user to land the crypto prep patches".

It could, but also it seems like it just makes it more complicated to
force the verifying agent to use a combination of netlink and sysfs.

Jason