Message-ID: <CAKmqyKORk5n_b2DUDfCVmttE4T+S-LQvcp0NoQD_O7D-csdEvA@mail.gmail.com>
Date: Fri, 7 Mar 2025 11:04:23 +1000
From: Alistair Francis <alistair23@...il.com>
To: Dan Williams <dan.j.williams@...el.com>
Cc: Greg KH <gregkh@...uxfoundation.org>, 
	Miguel Ojeda <miguel.ojeda.sandonis@...il.com>, Alice Ryhl <aliceryhl@...gle.com>, 
	Alistair Francis <alistair@...stair23.me>, linux-cxl@...r.kernel.org, 
	linux-kernel@...r.kernel.org, lukas@...ner.de, linux-pci@...r.kernel.org, 
	bhelgaas@...gle.com, Jonathan.Cameron@...wei.com, 
	rust-for-linux@...r.kernel.org, akpm@...ux-foundation.org, 
	boqun.feng@...il.com, bjorn3_gh@...tonmail.com, wilfred.mallawa@....com, 
	ojeda@...nel.org, a.hindborg@...nel.org, tmgross@...ch.edu, gary@...yguo.net, 
	alex.gaynor@...il.com, benno.lossin@...ton.me, 
	Alistair Francis <alistair.francis@....com>
Subject: Re: [RFC v2 09/20] PCI/CMA: Expose in sysfs whether devices are authenticated

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

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.

So I don't think this really limits code re-use. Obviously there might
need to be some refactoring to share the code, but that will be true
of C or Rust code.

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

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

I'm happy to help maintain the C / Rust code and help refactor as
required. The current ABI to this library is all "C style" Rust to
keep it simple and easily compatible with the out of tree C SPDM
implementation and callers of the code.

So hopefully it doesn't require much Rust knowledge to refactor the ABI.

This is the type of feedback that I wanted to get though. Before this
goes too far is it something that is going to be accepted upstream?

Alistair

Powered by blists - more mailing lists