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

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
side, when the Rust side is not ready / able to invest in some ABI
integrations that C consumers need.

Otherwise this thread seems to be suggesting that people like me need to
accelerate nascent cross C / Rust refactoring skills, or lean on Rust
folks to care about that refactoring work.