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

[Dan Williams <dan.j.williams@intel.com>]

Alistair Francis wrote:
> On Thu, Mar 6, 2025 at 5:55 AM Dan Williams <dan.j.williams@intel.com> wrote:
> >
> > Alistair Francis wrote:
> > > On Fri, Feb 28, 2025 at 5:33 AM Greg KH <gregkh@linuxfoundation.org> 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@linuxfoundation.org> 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?

   Are all users served by Rust SPDM?:
   Once the device ecosystem matures can all architectures and
   distributions get their needs met with a Rust dependency?