Re: [RFC PATCH 2/4] spdm: Introduce a library for DMTF SPDM

["David E. Box" <david.e.box@linux.intel.com>]

On Tue, 2022-03-01 at 09:59 +0000, Jonathan Cameron wrote:
> On Mon, 28 Feb 2022 18:13:27 +0000
> "Box, David E" <david.e.box@intel.com> wrote:
> 
> > 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.
> > 
> 
> Hi David,
> 
> I messed this up.
> 
> Some discussion of this took place on the linaro open discussions
> list
> and I posted a version there to enable some testing which has the
> missing file.
> Note I only did minimal testing against that tree and have had one
> verbal report
> of a minor bug (without details...)
> 
> https://op-lists.linaro.org/archives/list/linaro-open-discussions@op-lists.linaro.org/thread/5QU65B6Q74B3B4ESR7W5HER5HQ6WF4EQ/
> 
> It's rather dated now so I'll do a rebase and post this hopefully
> later
> this week given you are interested.
> Note I haven't done any work on this for some time...
> 
> Curious though - what transport are people looking at?
> I was planning to do MCTP over VDM at somepoint, but are we talking
> something truely custom?  If so any plans to upstream as
> I'd love a second transport to prove out the layering?

Thanks for the link. Definitely interested so please do cc me on future
patches. I'm particularly interested in the SPDM library since I'm
looking at this for use with a device specific transport. I'll let you
know if/when there's something to upstream. Thanks.

David

> 
> 
> Thanks,
> 
> Jonathan
> 
> 
> 
> > 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...