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

[Jason Gunthorpe <jgg@nvidia.com>]

On Thu, Feb 19, 2026 at 04:07:58PM +0100, Lukas Wunner wrote:
> 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.

I'm arguing there are two very different steps here that must be kept
separate. Verification is done when the device is first seen and the
kernel is told it is OK to use the device.

A same-device check is performed if an already verified and accepted
device resumes or RAS's in some way.

same-device does not mean run a kernel verification against the kernel
keyring, as a second verification could be tricked into accepting
something that has changed and defeat the userspace verifier.

Instead the implementation should capture information when the device
is accepted by the verifier and on resume/RAS it should compare the
device against that captured information and determine if it is still
the same device.

The key north star must be that the userspace verifier alone decides
if the device is acceptable and if the kernel is configured to
auto-re-accept the device later on RAS/resume it must not permit a
device that is different from what userspace approved. In other words
it is not a verification on resume, it is just a kernel side
confirmation the device hasn't been changed.

Hence no keyring should be involved in resume.

I understand the tempatation to just run a kernel verification twice,
and it is OK if your use cases are limited to a kernel verifier, but
it doesn't compose very well with a userspace verfier at all and gives
us two very different frameworks.

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

I have said what I'd like in a few ways now.

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

We definitely need to ensure we build something where userspace is in
fully in charge.

I don't have an objection to an optional, useful for embedded, kernel
side verifier that uses the cma ring.

What I'm focusing on is that it be coherent with the whole complex
verifier flows we need, not just its own seperate different thing. So
replacing the userspace verifier with a kernel verifier is no
issue. Making it so you HAVE to use the kernel verifier to get certain
functionality like RAS is objectionable.

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

This is also not a very realistic scenario, there is no point to copy
a certificate from a device into the cma key ring. If you want to
trust the device as is without any verification then just accept it as
is with a trivial userspace "verifier".

If you want a kernel side verifier the realistic scenario is to bake
the permitted certificates into the image or kernel and/or have
busybox load them into the keyring at boot.

Jaason