On Mon, 28 Feb 2022 18:13:27 +0000 "Box, David E" <david.e.box@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx/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, Jonathan > David > > > > -----Original Message----- > > From: Dan Williams <dan.j.williams@xxxxxxxxx> > > Sent: Friday, February 18, 2022 2:06 PM > > To: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx> > > Cc: linux-cxl@xxxxxxxxxxxxxxx; Linux PCI <linux-pci@xxxxxxxxxxxxxxx>; > > open list:KEYS-TRUSTED <keyrings@xxxxxxxxxxxxxxx>; Chris Browy > > <cbrowy@xxxxxxxxxxxxxxxx>; Linuxarm <linuxarm@xxxxxxxxxx>; Lorenzo > > Pieralisi <lorenzo.pieralisi@xxxxxxx>; Bjorn Helgaas > > <bjorn@xxxxxxxxxxx>; Jeremy Kerr <jk@xxxxxxxxxxxxxxxxxxxx>; Box, David > > E <david.e.box@xxxxxxxxx> > > 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@xxxxxxxxxx> 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@xxxxxxxxxx> > > > --- > > > 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@xxxxxxxxxx> > > > + */ > > > + > > > +#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...
