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

[dan.j.williams]

dan.j.williams@ wrote:
[..]
> > For that caching the public key bit, I'm not clear on whether you intend
> > to do that from kernel side (which I think I'd prefer) or have user space
> > squirt that key back in again?  If we are doing it in kernel we can
> > at least always verify the transcript is self consistent and refuse to
> > give anything to user space if it's not consistent (other than debug material).
> > By self consistent I mean we verify the signature against the device provided
> > cert (might as well verify whole chain as that's trivial given we have to partly
> > parse them anyway to find the cert).  I don't think it maters hugely if
> > we do this in kernel beyond advantage of removing a few foot guns and
> > simplifying the userpace interface to "I'm fine with the provided transcript
> > for use when I'm not here next time" write. Disadvantage is we use the
> > cert parsing code (which is there anyway) and parse it all twice - once
> > in kernel and probably again in userspace or at some remote verifier.
> 
> Right, the proposal is cache the public-key from pci_tsm_ops::connect()
> and at least require that the resulting transcript from that session
> establishment is properly self-signed. No point in continuing with a TSM
> implementation that is not self-consistent.

So I ended up dropping this bit of the proposal because there is no need
for the kernel to be involved in any decision about the validity and
sufficiency of device evidence. Userspace has everything it needs to
make that initial determination. "Authenticated" simply means "evidence
ready".

Automatic device recovery into the TCB is a separate concern that needs
to be prepared to handle more than just "is this device able to generate
a fresh signature with the same cert chain that userspace saw before".
Yes, that is a minimal requirement but not sufficient for many cases.
For example cases that want to validate measurements, interface reports,
or opt-out of recovery because SPDM session loss is fatal.

I had a chat with Lukas about what I think that looks like this morning
and offered to summarize that in this thread. Note, this description is
assuming the drivers/pci/tsm/evidence.c implementation started here [1].

[1]: http://lore.kernel.org/20260303000207.1836586-9-dan.j.williams@xxxxxxxxx

Authenticate a device
=====================
Look in /sys/class/tsm to find a tsmN device which will be either an
instance associated with native kernel PCI CMA/SPDM or a platform tsm
like the one provided by AMD SEV-TIO, ARM CCA, Intel TDX, etc...

echo tsmN > /sys/bus/pci/devices/$device/tsm/connect

Once that succeeds the PCI/TSM evidence netlink interface is available
to dump any signatures created during that session establishment.

After userspace is happy with that evidence it can bind a driver.

If running in a confidential VM where the TSM driver is capable of
securing more than just an SPDM session the interface is:

echo tsmN > /sys/bus/pci/devices/$device/tsm/lock

Similar evidence can be collected, and when userspace is happy with it
it can accept the device:

echo 1 > /sys/bus/pci/devices/$device/tsm/accept

...and bind a driver.

Auto-recover device (future work)
=================================
By default, devices fall out of the TCB on recovery events for the TDISP
case and need userspace to rerun the lock and accept flow. For the
native SPDM CMA case the default is that the kernel continues to operate
the device post recovery and only userspace polling could detect device
replacement.

To go beyond those defaults the kernel needs userpsace to tell it how to
re-validate the device. I think that can be as simple as a netlink
message to store hashes of cert chains or measurements and then use
those in a new challenge / response with the device with a kernel
decided nonce. It can also be more sophisiticated than that. The
point is that it will be use case dependendent, policy driven, and
separate from the "connect" or "lock" flow.

The equivalent behavior to what is present in this SPDM proposal is
extend drivers/pci/tsm/evidence.c to add a netlink operation that tells
the kernel to cache the public-key and challenge the device regenerate a
valid signature. Then plumb all the recovery paths to call a new
'struct pci_tsm_ops::revalidate()' operation in all the same places
where this patch set wants to reauthenticate. Later when something more
sophisticated than "challenge the device to create a signature" comes
along it can reuse those revalidate() hooks.

Auto-authenticate devices (future work)
=======================================
One of the nice aspects of the .cma keyring proposal is that it would be
amenable to CONFIG_SYSTEM_EXTRA_CERTIFICATE. Give the kernel the
certificate to validate device signatures without needing to ask
userspace. That still comes with the caveat that it is not sufficient
for the cases that care about more than mere signature verification. I
am not opposed to that being built just that it is not a policy that is
implied by the device "authenticated" state. It is policy that is
incremental to the base which makes no assumptions about kernel
verification.