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 for Android: free password hash cracker in your pocket

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

Message-ID: <Z0H_TYOPegVrkM9o@wunner.de>
Date: Sat, 23 Nov 2024 17:14:05 +0100
From: Lukas Wunner <lukas@...ner.de>
To: Bjorn Helgaas <helgaas@...nel.org>
Cc: Alistair Francis <alistair@...stair23.me>, 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, alistair23@...il.com,
	alex.gaynor@...il.com, gary@...yguo.net, aliceryhl@...gle.com
Subject: Re: [RFC 3/6] lib: rspdm: Initial commit of Rust SPDM

On Fri, Nov 22, 2024 at 11:31:04AM -0600, Bjorn Helgaas wrote:
> On Fri, Nov 15, 2024 at 03:46:13PM +1000, Alistair Francis wrote:
> > +++ 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"
> > +	help
> > +	  The Rust implementation of the Security Protocol and Data Model (SPDM)
> > +	  allows for device authentication, measurement, key exchange and
> > +	  encrypted sessions.
> > +
> > +	  Crypto algorithms negotiated with SPDM are limited to those enabled
> > +	  in .config.  Drivers selecting SPDM therefore need to also select
> > +	  any algorithms they deem mandatory.
> 
> Maybe this (and config SPDM) should be tweaked to mention drivers that
> *depend* on SPDM or RSPDM, since they no longer use "select"?
> 
> PCI_CMA, which currently depends on SPDM, doesn't really look like a
> "driver", so maybe it should say "users of SPDM" or "features
> depending on SPDM" or something?

I anticipate that the SPDM library will eventually be used by at least
two actual drivers:  NVMe and an x86 platform driver for Intel SDSi
(Software Defined Silicon).  SCSI and ATA may follow suit.

Thus, although the PCI core may be the first user, the majority of
users will likely be actual drivers, which is why I've used that
term in the help text.

Referring to "users" instead of "drivers" may be misunderstood as
users in the sense of people using the kernel.  In particular because
the help text is seen by such users.  The terms "subsystems" or "features"
don't seem to be as clear as "drivers" IMO.

Thanks,

Lukas