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

[Lukas Wunner <lukas@wunner.de>]

On Thu, Feb 19, 2026 at 08:41:19AM -0400, Jason Gunthorpe wrote:
> 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.

The way this works in my series (and I presume Alistair's) is that
trusted root certificates for devices need to be added to the .cma
keyring.

This can be done from user space using keyctl(1) or some other utility
that can talk to the kernel's existing keyctl ABI.

It is also possible to link the .builtin_trusted_keys or .platform
keyrings into the .cma keyring and thereby declare anything trusted
that is used for UEFI Secure Boot.  Likewise blacklisted certificates
added to the .blacklisted keyring are rejected for SPDM device
authentication.  These are existing, well-established roots of trust
in the kernel that CMA simply inherits.  I think it is reasonable
to base auto-acceptance on these existing mechanisms.  No need to
reinvent the wheel.

If you want to trust exactly one specific End Entity certificate,
you could provision an SPDM slot with that certificate, add it to
the .cma keyring and clean out all the other 7 SPDM certificate slots
on the device.

> > 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.
> 
> Honestly, I'm reluctant to add permanent sysfs uAPI just for temporary
> debugging. Put it in debugfs.

Exposure of the certificates in the SPDM slots is not for debugging,
it's just super convenient for day-to-day use.

> Having to find/remember some baroque openssl command line with a
> million options is not reasonable for a production kind of
> environment.

Personally I find something like the following neither baroque nor
unreasonable:

  # What's the certificate chain in slot0?
  openssl storeutl -text /sys/bus/pci/devices/0000:03:00.0/certificates/slot0

  # Fingerprint of root cert in slot0, does it match what vendor claims?
  openssl x509 -fingerprint -in /sys/bus/pci/devices/0000:03:00.0/certificates/slot0

  # Looks good, let's trust it:
  keyctl padd asymmetric "" %:.cma < /sys/bus/pci/devices/0000:03:00.0/certificates/slot0

> There should be a tool suite that runs on top of this stuff and
> presents a sensible user experiance, with man pages and so on.

Device authentication is currently trickling down from server to
client to embedded/edge devices and you don't want to require users
to install a tool suite on space-constrained embedded devices where
busybox + openssl is otherwise enough, doubly so with skyrocketing
eMMC prices.

Thanks,

Lukas