Re: [RFC v3 00/27] lib: Rust implementation of SPDM
From: dan.j.williams
Date: Wed Feb 18 2026 - 18:42:18 EST
[ add Aneesh, Alexey, and Yilun ]
Alistair Francis wrote:
[..]
> I'm currently thinking of splitting this in 3 parts. One for the
> ground work patches (crypto), one for SPDM (without netlink) and then
> a final one for netlink support.
>
> I feel that this RFC proves netlink can work, which is important. For
> SPDM the authenticated syfs attribute is enough to provide usefulness
> to userspace to merge that while sending the netlink later.
>
> That way hopefully everything is a little more self contained, but
> still has users and value to justify being merged.
The split sounds good. I chatted with Lukas a bit this morning he
rightly pointed out that the crypto pre-work does not really stand on
its own without a user.
However, I notice that Aneesh needs x509 certificate parsing for his TSM
driver [1], I think TDX would benefit from the same to offload needing
to specify the wall-clock time to the module [2] for cert verification,
and SEV-TIO (already upstream) is currently missing any facility for the
host to attest the device.
[1]: http://lore.kernel.org/20250728135216.48084-17-aneesh.kumar@xxxxxxxxxx
[2]: http://lore.kernel.org/20251117022311.2443900-9-yilun.xu@xxxxxxxxxxxxxxx
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.
This provides immediate value to the TSM "connect" flow and is smaller
than depending on the SPDM library as the first consumer. It also feels
like useful refactoring to split 'struct spdm_state' into context for a
session initiator (SPDM library) and context for the artifacts (certs +
measurements produced by either SPDM library or a TSM).