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

[Dan Williams <dan.j.williams@intel.com>]

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...