On Sat, Nov 16, 2024 at 8:54 AM Dan Williams <dan.j.williams@xxxxxxxxx> wrote: > > Alistair Francis wrote: > > This is the initial commit of the Rust SPDM library. It is based on and > > compatible with the C SPDM library in the kernel (lib/spdm). > > > > Signed-off-by: Alistair Francis <alistair@xxxxxxxxxxxxx> > [..] > > diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig > > index 690a2a38cb52..744d35d28dc7 100644 > > --- a/drivers/pci/Kconfig > > +++ b/drivers/pci/Kconfig > > @@ -128,7 +128,7 @@ config PCI_CMA > > select CRYPTO_SHA256 > > select CRYPTO_SHA512 > > select PCI_DOE > > - depends on SPDM > > + depends on SPDM || RSPDM > > help > > Authenticate devices on enumeration per PCIe r6.2 sec 6.31. > > A PCI DOE mailbox is used as transport for DMTF SPDM based > > diff --git a/lib/Kconfig b/lib/Kconfig > > index 4db9bc8e29f8..a47650a6757c 100644 > > --- a/lib/Kconfig > > +++ b/lib/Kconfig > > @@ -754,6 +754,23 @@ config SPDM > > in .config. Drivers selecting SPDM therefore need to also select > > any algorithms they deem mandatory. > > > > +config RSPDM > > + bool "Rust SPDM" > > + select CRYPTO > > + select KEYS > > + select ASYMMETRIC_KEY_TYPE > > + select ASYMMETRIC_PUBLIC_KEY_SUBTYPE > > + select X509_CERTIFICATE_PARSER > > + depends on SPDM = "n" > > I trust these last 2 diff hunks never actually go upstream, right? I.e. > if the kernel has no SPDM today it should not plan to carry 2 > implementations just for language differences. > > I am not sure if that is already the plan, but the cover letter seemed > ambiguous with its "maintaining compatibility" statement. On one hand, > that does not make sense when this is brand new upstream code (i.e. C > version is not even in linux-next), and there are no chances for > regressions. Just embrace the attempt to be a Rust library for C > consumers or otherwise help the C version along. > > However, if "maintain compatibility" means "make it easy for the > work-in-progress C-effort to switch dependencies", then that makes > sense and is worth clarifying in the next posting. It is ambiguous, because I'm not really sure what the best approach is. I think everyone agrees SPDM in the kernel is the way to go and there is a work in progress C implementation. I think that SPDM is the exact type of library that would be great to be written in Rust. My only worry is that Rust in the kernel is still experimental. I don't want to have a Rust SPDM implementation that isn't used or enabled by default because Rust is still experimental, hence the option of supporting the C or the Rust implementation. If a Rust only implementation is acceptable, then I'm happy to switch this series to "make it easy for the work-in-progress C-effort to switch dependencies". At which point I can continue to support more SPDM features here and work on a better userspace interface as discussed at Plumbers. Alistair
