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

[dan.j.williams]

Lukas Wunner wrote:
> On Wed, Feb 18, 2026 at 08:56:14PM -0400, Jason Gunthorpe wrote:
> > 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.
> 
> It has turned out to be super convenient to expose the 8 slots with
> certificate chains in sysfs for direct examination with openssl and
> similar tools, without having to go through netlink.
> 
> Originally the plan was to make the certificates/slot[0..7] files
> also writable and the kernel would implicitly perform a SET_CERTIFICATE
> SPDM exchange with the device when writing to those files.
> Unfortunately with SPDM 1.3 the spec editors made things more
> complicated, *cough* sorry *more flexible* with additional CertModel
> and KeyPairID attributes.  That additional complexity makes it less
> suitable for sysfs, hence for *provisioning* netlink is indeed the
> better choice.  But just for *reading* the certificates in the slots,
> sysfs exposure is very useful.

Useful, but not required, right? The consistency argument from Jason is
growing on me. Merely validating the certificate chain is not sufficient
to establish trust in the device configuration. So, if a $pci_auth_tool
is needed in the flow at all is there a practical difference between:

	$pci_auth_tool cert --device $dev --slot $slot | openssl

...and:

	cat /sys/bus/pci/devices/$dev/certificates/$slot | openssl