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