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

[Lukas Wunner <lukas@wunner.de>]

On Thu, Feb 19, 2026 at 10:31:29AM -0400, Jason Gunthorpe wrote:
> On Thu, Feb 19, 2026 at 03:15:34PM +0100, Lukas Wunner wrote:
> > 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.

On resume from system sleep, the device is put into D0 already in the
->resume_noirq() phase and drivers are free to access it already at
that point.  However a verifier in user space cannot be queried
at that point because user space is still frozen.

Likewise after recovery from DPC or AER, the device has been reset
and needs to be reauthenticated, yet user space may be unavailable
because the device that has been reset may contain the root partition
or may be the NIC that you need to query your remote attestation service.

There is no way around some form of in-kernel device authentication
to accommodate such use cases.

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

Well please be constructive and propose something better.

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

No problem at all.  The kernel will merely use the .cma keyring for
its own notion of an authenticated device.

However if there is no trusted root cert in the .cma keyring,
the kernel will still multicast the signature received from the
device via netlink, so your user space tool can ask the remote
attestation service and if it responds affirmatively, you trust
the device.

So you can either use the .cma keyring for in-kernel authentication
or you can use your user space utility.

But you can't rely on user space if you want seamless re-authentication
after a system sleep transition or error recovery.

We can discuss a way for user space to force the kernel into
considering a device authenticated.  E.g. writing "force" to
the "authenticated" attribute may tell the kernel that it's
a trustworthy device irrespective of the .cma keyring.
So you'd perform remote attestation and if successful,
tell the kernel to consider the device trusted.

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

I used to be an admin for 2 decades and my experience is that
openssl usage has just become muscle memory, but YMMV. :)

Thanks,

Lukas