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

[Jason Gunthorpe <jgg@nvidia.com>]

On Thu, Feb 19, 2026 at 03:15:34PM +0100, Lukas Wunner wrote:
> 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.

I really don't like this from a verification perspective. We don't
want the kernel checking signatures, that is the verifier's job.

And a general keyring based proeprty is not at all the same as 'this
device must present exactly the same certification and attesation
after resume'

> 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.

It depends what you are building. We've been focused on external
verification so this is not at all desirable.

Something else, maybe some kind of internal verification for embedded
is a quite different story. The two cases still need to compose
sensibly within the kernel though.

> > 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

That's exactly the baroque I'm talking about, no server admin is going
to want to grapple with that..

> 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.

Maybe, but is this a real thing where someone would run busybox and
want some minimal self-verification?

Jason