From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: "Box, David E" <david.e.box@intel.com>
Cc: "Williams, Dan J" <dan.j.williams@intel.com>,
"linux-cxl@vger.kernel.org" <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>,
"'david.e.box@linux.intel.com'" <david.e.box@linux.intel.com>
Subject: Re: [RFC PATCH 2/4] spdm: Introduce a library for DMTF SPDM
Date: Tue, 1 Mar 2022 09:59:37 +0000 [thread overview]
Message-ID: <20220301095937.00002c5e@Huawei.com> (raw)
In-Reply-To: <MW3PR11MB452200EBA0E813A1A4E8D8C4A1019@MW3PR11MB4522.namprd11.prod.outlook.com>
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,
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...
next prev parent reply other threads:[~2022-03-01 9:59 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-04 16:18 [RFC PATCH 0/4] PCI/CMA and SPDM library Jonathan Cameron
2021-08-04 16:18 ` [RFC PATCH 1/4] lib/asn1_encoder: Add a function to encode many byte integer values Jonathan Cameron
2021-08-04 16:18 ` [RFC PATCH 2/4] spdm: Introduce a library for DMTF SPDM Jonathan Cameron
2022-02-18 22:05 ` Dan Williams
2022-02-28 18:13 ` Box, David E
2022-03-01 9:59 ` Jonathan Cameron [this message]
2022-03-02 21:34 ` David E. Box
2021-08-04 16:18 ` [RFC PATCH 3/4] PCI/CMA: Initial support for Component Measurement and Authentication ECN Jonathan Cameron
2021-09-17 16:22 ` Jonathan Cameron
2021-08-04 16:18 ` [RFC PATCH 4/4] cxl/pci: Add really basic CMA authentication support Jonathan Cameron
2021-08-05 16:43 ` [RFC PATCH 0/4] PCI/CMA and SPDM library Jonathan Cameron
2021-08-31 12:55 ` Jonathan Cameron
2021-11-17 17:46 ` Chris Browy
2021-11-18 11:54 ` Jonathan Cameron
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220301095937.00002c5e@Huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=bjorn@helgaas.com \
--cc=cbrowy@avery-design.com \
--cc=dan.j.williams@intel.com \
--cc=david.e.box@intel.com \
--cc=david.e.box@linux.intel.com \
--cc=jk@codeconstruct.com.au \
--cc=keyrings@vger.kernel.org \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=lorenzo.pieralisi@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).