[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-keyrings
Subject:    RE: [RFC PATCH 2/4] spdm: Introduce a library for DMTF SPDM
From:       "Box, David E" <david.e.box () intel ! com>
Date:       2022-02-28 18:13:27
Message-ID: MW3PR11MB452200EBA0E813A1A4E8D8C4A1019 () MW3PR11MB4522 ! namprd11 ! prod ! outlook ! com
[Download RAW message or body]

Hi Jonathan,

I'd like to test this patch with a custom transport but there's a reference to spdm.h \
that isn't here. Also, have you looked at measurement support yet? Thanks.

David


> -----Original Message-----
> From: Dan Williams <dan.j.williams@intel.com>
> Sent: Friday, February 18, 2022 2:06 PM
> To: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> Cc: linux-cxl@vger.kernel.org; Linux PCI <linux-pci@vger.kernel.org>;
> open list:KEYS-TRUSTED <keyrings@vger.kernel.org>; Chris Browy
> <cbrowy@avery-design.com>; Linuxarm <linuxarm@huawei.com>; Lorenzo
> Pieralisi <lorenzo.pieralisi@arm.com>; Bjorn Helgaas
> <bjorn@helgaas.com>; Jeremy Kerr <jk@codeconstruct.com.au>; Box, David
> E <david.e.box@intel.com>
> Subject: Re: [RFC PATCH 2/4] spdm: Introduce a library for DMTF SPDM
> 
> On Wed, Aug 4, 2021 at 9:23 AM Jonathan Cameron
> <Jonathan.Cameron@huawei.com> wrote:
> > 
> > The Security Protocol and Data Model (SPDM) defines messages, data
> > objects and sequences for performing message exchanges between
> devices
> > over various transports and physical media.
> > 
> > As the kernel supports several possible transports (mctp, PCI DOE)
> > introduce a library than can in turn be used with all those
> transports.
> > 
> > There are a large number of open questions around how we do this that
> > need to be resolved. These include:
> > *  Key chain management
> > - Current approach is to use a keychain provide as part of per
> transport
> > initialization for the root certificates which are assumed to be
> > loaded into that keychain, perhaps in an initrd script.
> > - Each SPDM instance then has its own keychain to manage its
> > certificates. It may make sense to drop this, but that looks
> like it
> > will make a lot of the standard infrastructure harder to use.
> > *  ECC algorithms needing ASN1 encoded signatures.  I'm struggling
> to find
> > any specification that actual 'requires' that choice vs raw data,
> so my
> > guess is that this is a question of existing usecases (x509 certs
> seem
> > to use this form, but CHALLENGE_AUTH SPDM seems to use raw data).
> > I'm not sure whether we are better off just encoding the
> signature in
> > ASN1 as currently done in this series, or if it is worth a
> tweaking
> > things in the crypto layers.
> > *  Lots of options in actual implementation to look at.
> > 
> > Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > ---
> > lib/Kconfig  |    3 +
> > lib/Makefile |    2 +
> > lib/spdm.c   | 1196
> ++++++++++++++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 1201 insertions(+)
> > 
> > diff --git a/lib/Kconfig b/lib/Kconfig index
> > ac3b30697b2b..0aa2fef6a592 100644
> > --- a/lib/Kconfig
> > +++ b/lib/Kconfig
> > @@ -704,3 +704,6 @@ config PLDMFW
> > 
> > config ASN1_ENCODER
> > tristate
> > +
> > +config SPDM
> > +       tristate
> > diff --git a/lib/Makefile b/lib/Makefile index
> > 2cc359ec1fdd..566166d6936e 100644
> > --- a/lib/Makefile
> > +++ b/lib/Makefile
> > @@ -282,6 +282,8 @@ obj-$(CONFIG_PERCPU_TEST) += percpu_test.o
> > obj-$(CONFIG_ASN1) += asn1_decoder.o
> > obj-$(CONFIG_ASN1_ENCODER) += asn1_encoder.o
> > 
> > +obj-$(CONFIG_SPDM) += spdm.o
> > +
> > obj-$(CONFIG_FONT_SUPPORT) += fonts/
> > 
> > hostprogs      := gen_crc32table
> > diff --git a/lib/spdm.c b/lib/spdm.c
> > new file mode 100644
> > index 000000000000..3ce2341647f8
> > --- /dev/null
> > +++ b/lib/spdm.c
> > @@ -0,0 +1,1196 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * DMTF Security Protocol and Data Model
> > + *
> > + * Copyright (C) 2021 Huawei
> > + *     Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > + */
> > +
> > +#include <linux/asn1_encoder.h>
> > +#include <linux/asn1_ber_bytecode.h>
> > +#include <linux/bitfield.h>
> > +#include <linux/cred.h>
> > +#include <linux/dev_printk.h>
> > +#include <linux/digsig.h>
> > +#include <linux/idr.h>
> > +#include <linux/key.h>
> > +#include <linux/module.h>
> > +#include <linux/random.h>
> > +#include <linux/spdm.h>
> > +
> > +#include <crypto/akcipher.h>
> > +#include <crypto/hash.h>
> > +#include <crypto/public_key.h>
> > +#include <keys/asymmetric-type.h>
> > +#include <keys/user-type.h>
> > +#include <asm/unaligned.h>
> > +
> > +/*
> > + * Todo
> > + * - Secure channel setup.
> > + * - Multiple slot support.
> > + * - Measurement support (over secure channel or within
> CHALLENGE_AUTH.
> > + * - Support more core algorithms (not CMA does not require them,
> but may use
> > + *   them if present.
> > + * - Extended algorithm, support.
> > + */
> > +/*
> > + * Discussions points
> > + * 1. Worth adding an SPDM layer around a transport layer?
> 
> I came here to say yes to this question. I am seeing interest in SPDM
> outside of a DOE transport.
> 
> Hope to find my way back to testing these bits out soon...


[prev in list] [next in list] [prev in thread] [next in thread]