Re: [RFC v2 09/20] PCI/CMA: Expose in sysfs whether devices are authenticated

[Alistair Francis]

On Sat, Mar 8, 2025 at 9:38 AM Dan Williams <dan.j.williams@xxxxxxxxx> wrote:
>
> Alistair Francis wrote:
> > On Thu, Mar 6, 2025 at 5:55 AM Dan Williams <dan.j.williams@xxxxxxxxx> wrote:
> > >
> > > Alistair Francis wrote:
> > > > On Fri, Feb 28, 2025 at 5:33 AM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> > > > >
> > > > > On Thu, Feb 27, 2025 at 05:45:02PM +0100, Miguel Ojeda wrote:
> > > > > > On Thu, Feb 27, 2025 at 1:01 PM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> > > > > > >
> > > > > > > Sorry, you are right, it does, and of course it happens (otherwise how
> > > > > > > would bindings work), but for small functions like this, how is the C
> > > > > > > code kept in sync with the rust side?  Where is the .h file that C
> > > > > > > should include?
> > > >
> > > > This I can address with something like Alice mentioned earlier to
> > > > ensure the C and Rust functions stay in sync.
> > > >
> > > > > >
> > > > > > What you were probably remembering is that it still needs to be
> > > > > > justified, i.e. we don't want to generally/freely start replacing
> > > > > > "individual functions" and doing FFI both ways everywhere, i.e. the
> > > > > > goal is to build safe abstractions wherever possible.
> > > > >
> > > > > Ah, ok, that's what I was remembering.
> > > > >
> > > > > Anyway, the "pass a void blob from C into rust" that this patch is doing
> > > > > feels really odd to me, and hard to verify it is "safe" at a simple
> > > > > glance.
> > > >
> > > > I agree, it's a bit odd. Ideally I would like to use a sysfs binding,
> > > > but there isn't one today.
> > > >
> > > > I had a quick look and a Rust sysfs binding implementation seems like
> > > > a lot of work, which I wasn't convinced I wanted to invest in for this
> > > > series. This is only a single sysfs attribute and I didn't want to
> > > > slow down this series on a whole sysfs Rust implementation.
> > > >
> > > > If this approach isn't ok for now, I will just drop the sysfs changes
> > > > from the series so the SPDM implementation doesn't stall on sysfs
> > > > changes. Then come back to the sysfs attributes in the future.
> > >
> > > This highlights a concern I have about what this means for ongoing
> > > collaboration between this native PCI device-authentication (CMA)
> > > enabling and the platform TEE Security Manager (TSM) based
> > > device-security enabling.
> > >
> > > First, I think Rust for a security protocol like SPDM makes a lot of
> > > sense. However, I have also been anticipating overlap between the ABIs
> > > for conveying security collateral like measurements, transcripts, nonces
> > > etc between PCI CMA and PCI TSM. I.e. potential opportunities to
> > > refactor SPDM core helpers for reuse. A language barrier and an ABI
> > > barrier (missing Rust integrations for sysfs and netlink ABIs that were
> > > discussed at Plumbers) limits that potential collaboration.
> >
> > I see your concern, but I'm not sure it's as bad as you think.
> >
> > We will need to expose the Rust code to C no matter what. The CMA,
> > NVMe, SATA and SAS is all C code, so the Rust library will have a nice
> > C style ABI to allow those subsystems to call the code.
>
> That indeed alleviates a significant amount of the concern. I.e.
> multiple planned C users makes it less likely that the needs of yet one
> more C user, PCI TSM, get buried deep in the Rust implementation.
>
> > The sysfs issue is mostly because I am trying to write as much of the
> > sysfs code in Rust, but there aren't bindings yet.
> >
> > So if we want to re-use code (such as measurements, transcripts or
> > nonces) we just need to expose a C style function in Rust which can
> > then can then be used.
>
> Makes sense.
>
> > > Now if you told me the C SPDM work will continue and the Rust SPDM
> > > implementation will follow in behind until this space settles down in a
> > > year or so, great. I am not sure it works the other way, drop the C
> >
> > That was kind of my original plan (see the first RFC), but maintaining
> > both, with at least one being out of tree, will be a huge pain and
> > prone to breakage.
> >
> > Also I suspect the Rust implementation will struggle to keep up if the
> > C version is merged (and hence has more people looking at it) compared
> > to just me working on the Rust code.
>
> The practical questions that come to mind are:
>
>    Do we have time?:
>    I.e. How long can we continue to develop both out of tree? Presumably,
>    until the device ecosystem matures, when is that?

I guess that's a difficult question to answer. There are SPDM capable
devices on the market now ([1] and [2] for example).

While the ecosystem isn't mature, having something upstream makes it a
lot easier to build and improve on. For example MCTP/I2C/SMBus support
could be built on top of this series by someone if/when they are
interested. We are also working on SPDM storage support, which builds
on this. It is always harder to work with when the code is out of
tree.

The other big plus of having something upstream is it will encourage
vendors to test against the kernel implementation. Which might help
catch buggy devices before they ship.

Note that at the moment the C and Rust implementations are ABI
compatible and can be easily swapped out.

>
>    Are all users served by Rust SPDM?:

That's my hope

>    Once the device ecosystem matures can all architectures and
>    distributions get their needs met with a Rust dependency?

That's a good question. I don't have a complete answer. I do think all
architectures that are interested in SPDM (think servers and PC class)
support Rust, so that should be ok.

As for distributions, I also think every major distro supports Rust,
so extending that to the kernel shouldn't be too difficult if it isn't
already supported today.

The decision is really up to the kernel community if you are ready for
this. Note that this series can't be merged today as it depends on
some other patches which aren't yet upstream. So this is still a
release or two away from being actually mergable.

1: https://www.microchip.com/en-us/tools-resources/reference-designs/ocp-power-supply-spdm-solution-demonstration-application
2: https://docs.nvidia.com/networking/display/nvidiadeviceattestationandcorimbasedreferencemeasurementsharingv20

Alistair