linux-kernel - Re: [RFC 3/6] lib: rspdm: Initial commit of Rust SPDM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKmqyKPXo1KdTSVsEZSUt4Fj8gaWgg8XJzf6E+FsuaeMOdFv1w@mail.gmail.com>
Date: Tue, 19 Nov 2024 14:24:54 +1000
From: Alistair Francis <alistair23@...il.com>
To: Dan Williams <dan.j.williams@...el.com>
Cc: Alistair Francis <alistair@...stair23.me>, lukas@...ner.de, Jonathan.Cameron@...wei.com, 
	linux-kernel@...r.kernel.org, rust-for-linux@...r.kernel.org, 
	akpm@...ux-foundation.org, bhelgaas@...gle.com, linux-pci@...r.kernel.org, 
	linux-cxl@...r.kernel.org, bjorn3_gh@...tonmail.com, ojeda@...nel.org, 
	tmgross@...ch.edu, boqun.feng@...il.com, benno.lossin@...ton.me, 
	a.hindborg@...nel.org, wilfred.mallawa@....com, alex.gaynor@...il.com, 
	gary@...yguo.net, aliceryhl@...gle.com
Subject: Re: [RFC 3/6] lib: rspdm: Initial commit of Rust SPDM

On Sat, Nov 16, 2024 at 8:54 AM Dan Williams <dan.j.williams@...el.com> 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@...stair23.me>
> [..]
> > 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