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

[Alistair Francis <Alistair.Francis@wdc.com>]

On Fri, 2026-05-01 at 18:34 -0700, Dan Williams (nvidia) wrote:
> Alistair Francis wrote:
> > On Fri, Apr 17, 2026 at 2:34 PM Lukas Wunner <lukas@wunner.de>
> > wrote:
> > > 
> > > On Thu, Apr 16, 2026 at 07:35:44PM -0700, Dan Williams wrote:
> > > > Later in the thread I proposed an alternative that instead of
> > > > supporting
> > > > 2 flavors of uapi through "authenticated", instead implement
> > > > CMA as
> > > > another TSM driver [1].
> > > > 
> > > > [1]:
> > > > http://lore.kernel.org/69976d7d39c60_2f4a1009@dwillia2-mobl4.notmuch
> > > 
> > > Please keep in mind though that CMA is just the PCIe adaption of
> > > SPDM,
> > > SPDM is not only needed for PCIe but also SCSI, ATA and possibly
> > > others
> > > and so implementing CMA as a TSM driver must not preclude use of
> > > SPDM
> > > in other subsystems.
> > 
> > That should be fine as the current SPDM implementation is
> > self-contained, but thanks for raising that.
> > 
> > Just to make sure I'm not going in the wrong direction, the idea
> > would
> > be to build on
> > 
> > https://lore.kernel.org/all/20260303000207.1836586-9-dan.j.williams@intel.com/
> > 
> > and add something like this?
> > 
> > ```
> > static const struct pci_tsm_ops pci_cma_tsm_ops = {
> >     .link_ops = {
> >         .probe        = pci_cma_tsm_probe,
> >         .remove        = pci_cma_tsm_remove,
> >         .connect    = pci_cma_tsm_connect,
> >         .disconnect    = pci_cma_tsm_disconnect,
> >     },
> >     .refresh_evidence    = pci_cma_tsm_refresh,
> > };
> > ```
> > 
> > The docs for `struct pci_tsm_ops` seem pretty TSM specific, so I
> > just
> > wanted to double check before going ahead.
> > 
> > That means all of the netlink stuff in this series can be dropped
> > and
> > we just use the TSM netlink (which might need some adjustments
> > then,
> > I'll have to double check)
> 
> Right, the above looks what I was expecting.

Great!

> 
> As for netlink, Lukas is right about non CMA use cases. The netlink
> interface will either need to move to be a generic "device evidence"
> facility, not scoped to PCI/TSM, or itself become a library that
> different producers of SPDM material can use to export it to
> userspace.

Yep, I think we have two options


1. This series approach, where SPDM measurements use their own netlink
interface and each transport mechanism looks exactly the same to
userspace. Which means we don't leverage TSM.

The obvious advantage is that each transport is more or less invisible
to userspace, but we don't tightly integrate with the transport
protocol.

2. The PCI TSM approach, where each SPDM transport mechanism has it's
own transport dependent way to provide the information to userspace.
PCI uses TSM, ATA/SCSI use their own thing ect.

The advantage here is we can more tightly integrate with the existing
infrastructure.

I'm open to either approach

Alistair