From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Lukas Wunner <lukas@wunner.de>,
Bjorn Helgaas <helgaas@kernel.org>,
David Howells <dhowells@redhat.com>,
Herbert Xu <herbert@gondor.apana.org.au>,
"David S. Miller" <davem@davemloft.net>,
David Woodhouse <dwmw2@infradead.org>,
James Bottomley <James.Bottomley@hansenpartnership.com>,
<linux-pci@vger.kernel.org>, <linux-cxl@vger.kernel.org>,
<linux-coco@lists.linux.dev>, <keyrings@vger.kernel.org>,
<linux-crypto@vger.kernel.org>, <linuxarm@huawei.com>,
David Box <david.e.box@intel.com>,
"Li, Ming" <ming4.li@intel.com>,
Ilpo Jarvinen <ilpo.jarvinen@linux.intel.com>,
Alistair Francis <alistair.francis@wdc.com>,
Wilfred Mallawa <wilfred.mallawa@wdc.com>,
Damien Le Moal <dlemoal@kernel.org>,
"Alexey Kardashevskiy" <aik@amd.com>,
Dhaval Giani <dhaval.giani@amd.com>,
Gobikrishna Dhanuskodi <gdhanuskodi@nvidia.com>,
Jason Gunthorpe <jgg@nvidia.com>, Peter Gonda <pgonda@google.com>,
Jerome Glisse <jglisse@google.com>,
Sean Christopherson <seanjc@google.com>,
"Alexander Graf" <graf@amazon.com>,
Samuel Ortiz <sameo@rivosinc.com>,
Eric Biggers <ebiggers@google.com>,
Stefan Berger <stefanb@linux.ibm.com>
Subject: Re: [PATCH v2 07/18] spdm: Introduce library to authenticate devices
Date: Thu, 18 Jul 2024 12:42:08 +0100 [thread overview]
Message-ID: <20240718124208.00002b72@Huawei.com> (raw)
In-Reply-To: <668cc61b230c4_102cc294c4@dwillia2-xfh.jf.intel.com.notmuch>
On Mon, 8 Jul 2024 22:09:47 -0700
Dan Williams <dan.j.williams@intel.com> wrote:
> Lukas Wunner wrote:
> > From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> >
> > The Security Protocol and Data Model (SPDM) allows for device
> > authentication, measurement, key exchange and encrypted sessions.
> >
> > SPDM was conceived by the Distributed Management Task Force (DMTF).
> > Its specification defines a request/response protocol spoken between
> > host and attached devices over a variety of transports:
> >
> > https://www.dmtf.org/dsp/DSP0274
> >
> > This implementation supports SPDM 1.0 through 1.3 (the latest version).
> > It is designed to be transport-agnostic as the kernel already supports
> > four different SPDM-capable transports:
> >
> > * PCIe Data Object Exchange, which is a mailbox in PCI config space
> > (PCIe r6.2 sec 6.30, drivers/pci/doe.c)
> > * Management Component Transport Protocol
> > (MCTP, Documentation/networking/mctp.rst)
> > * TCP/IP (in draft stage)
> > https://www.dmtf.org/sites/default/files/standards/documents/DSP0287_1.0.0WIP99.pdf
> > * SCSI and ATA (in draft stage)
> > "SECURITY PROTOCOL IN/OUT" and "TRUSTED SEND/RECEIVE" commands
> >
> > Use cases for SPDM include, but are not limited to:
> >
> > * PCIe Component Measurement and Authentication (PCIe r6.2 sec 6.31)
> > * Compute Express Link (CXL r3.0 sec 14.11.6)
> > * Open Compute Project (Attestation of System Components v1.0)
> > https://www.opencompute.org/documents/attestation-v1-0-20201104-pdf
> > * Open Compute Project (Datacenter NVMe SSD Specification v2.0)
> > https://www.opencompute.org/documents/datacenter-nvme-ssd-specification-v2-0r21-pdf
> >
> > The initial focus of this implementation is enabling PCIe CMA device
> > authentication. As such, only a subset of the SPDM specification is
> > contained herein, namely the request/response sequence GET_VERSION,
> > GET_CAPABILITIES, NEGOTIATE_ALGORITHMS, GET_DIGESTS, GET_CERTIFICATE
> > and CHALLENGE.
> >
> > This sequence first negotiates the SPDM protocol version, capabilities
> > and algorithms with the device. It then retrieves the up to eight
> > certificate chains which may be provisioned on the device. Finally it
> > performs challenge-response authentication with the device using one of
> > those eight certificate chains and the algorithms negotiated before.
> > The challenge-response authentication comprises computing a hash over
> > all exchanged messages to detect modification by a man-in-the-middle
> > or media error. The hash is then signed with the device's private key
> > and the resulting signature is verified by the kernel using the device's
> > public key from the certificate chain. Nonces are included in the
> > message sequence to protect against replay attacks.
> >
> > A simple API is provided for subsystems wishing to authenticate devices:
> > spdm_create(), spdm_authenticate() (can be called repeatedly for
> > reauthentication) and spdm_destroy(). Certificates presented by devices
> > are validated against an in-kernel keyring of trusted root certificates.
> > A pointer to the keyring is passed to spdm_create().
> >
> > The set of supported cryptographic algorithms is limited to those
> > declared mandatory in PCIe r6.2 sec 6.31.3. Adding more algorithms
> > is straightforward as long as the crypto subsystem supports them.
> >
> > Future commits will extend this implementation with support for
> > measurement, key exchange and encrypted sessions.
> >
> > So far, only the SPDM requester role is implemented. Care was taken to
> > allow for effortless addition of the responder role at a later stage.
> > This could be needed for a PCIe host bridge operating in endpoint mode.
> > The responder role will be able to reuse struct definitions and helpers
> > such as spdm_create_combined_prefix().
>
> Nice changelog.
>
> >
> > Credits: Jonathan wrote a proof-of-concept of this SPDM implementation.
> > Lukas reworked it for upstream.
> >
> > Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > Co-developed-by: Lukas Wunner <lukas@wunner.de>
> > Signed-off-by: Lukas Wunner <lukas@wunner.de>
> > ---
> > MAINTAINERS | 11 +
> > include/linux/spdm.h | 33 ++
> > lib/Kconfig | 15 +
> > lib/Makefile | 2 +
> > lib/spdm/Makefile | 10 +
> > lib/spdm/core.c | 425 ++++++++++++++++++++++
> > lib/spdm/req-authenticate.c | 704 ++++++++++++++++++++++++++++++++++++
> > lib/spdm/spdm.h | 520 ++++++++++++++++++++++++++
> > 8 files changed, 1720 insertions(+)
> > create mode 100644 include/linux/spdm.h
> > create mode 100644 lib/spdm/Makefile
> > create mode 100644 lib/spdm/core.c
> > create mode 100644 lib/spdm/req-authenticate.c
> > create mode 100644 lib/spdm/spdm.h
>
> I only have some quibbles below, but the broad strokes look good to me.
>
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index d6c90161c7bf..dbe16eea8818 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -20145,6 +20145,17 @@ M: Security Officers <security@kernel.org>
> > S: Supported
> > F: Documentation/process/security-bugs.rst
> >
> > +SECURITY PROTOCOL AND DATA MODEL (SPDM)
> > +M: Jonathan Cameron <jic23@kernel.org>
> > +M: Lukas Wunner <lukas@wunner.de>
> > +L: linux-coco@lists.linux.dev
> > +L: linux-cxl@vger.kernel.org
> > +L: linux-pci@vger.kernel.org
> > +S: Maintained
> > +T: git git://git.kernel.org/pub/scm/linux/kernel/git/devsec/spdm.git
> > +F: include/linux/spdm.h
> > +F: lib/spdm/
> > +
> > SECURITY SUBSYSTEM
> > M: Paul Moore <paul@paul-moore.com>
> > M: James Morris <jmorris@namei.org>
> > diff --git a/include/linux/spdm.h b/include/linux/spdm.h
> > new file mode 100644
> > index 000000000000..0da7340020c4
> > --- /dev/null
> > +++ b/include/linux/spdm.h
> > @@ -0,0 +1,33 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * DMTF Security Protocol and Data Model (SPDM)
> > + * https://www.dmtf.org/dsp/DSP0274
> > + *
> > + * Copyright (C) 2021-22 Huawei
> > + * Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > + *
> > + * Copyright (C) 2022-24 Intel Corporation
> > + */
> > +
> > +#ifndef _SPDM_H_
> > +#define _SPDM_H_
> > +
> > +#include <linux/types.h>
> > +
> > +struct key;
> > +struct device;
> > +struct spdm_state;
> > +
> > +typedef ssize_t (spdm_transport)(void *priv, struct device *dev,
> > + const void *request, size_t request_sz,
> > + void *response, size_t response_sz);
> > +
> > +struct spdm_state *spdm_create(struct device *dev, spdm_transport *transport,
> > + void *transport_priv, u32 transport_sz,
> > + struct key *keyring);
> > +
> > +int spdm_authenticate(struct spdm_state *spdm_state);
> > +
> > +void spdm_destroy(struct spdm_state *spdm_state);
> > +
> > +#endif
> > diff --git a/lib/Kconfig b/lib/Kconfig
> > index d33a268bc256..9011fa32af45 100644
> > --- a/lib/Kconfig
> > +++ b/lib/Kconfig
> > @@ -782,3 +782,18 @@ config POLYNOMIAL
> >
> > config FIRMWARE_TABLE
> > bool
> > +
> > +config SPDM
> > + tristate
> > + select CRYPTO
> > + select KEYS
> > + select ASYMMETRIC_KEY_TYPE
> > + select ASYMMETRIC_PUBLIC_KEY_SUBTYPE
> > + select X509_CERTIFICATE_PARSER
> > + help
> > + The Security Protocol and Data Model (SPDM) allows for device
> > + authentication, measurement, key exchange and encrypted sessions.
> > +
> > + Crypto algorithms negotiated with SPDM are limited to those enabled
> > + in .config. Drivers selecting SPDM therefore need to also select
> > + any algorithms they deem mandatory.
> > diff --git a/lib/Makefile b/lib/Makefile
> > index 3b1769045651..b2ef14d1fa71 100644
> > --- a/lib/Makefile
> > +++ b/lib/Makefile
> > @@ -301,6 +301,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/
> > +
> > obj-$(CONFIG_FONT_SUPPORT) += fonts/
> >
> > hostprogs := gen_crc32table
> > diff --git a/lib/spdm/Makefile b/lib/spdm/Makefile
> > new file mode 100644
> > index 000000000000..f579cc898dbc
> > --- /dev/null
> > +++ b/lib/spdm/Makefile
> > @@ -0,0 +1,10 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +#
> > +# DMTF Security Protocol and Data Model (SPDM)
> > +# https://www.dmtf.org/dsp/DSP0274
> > +#
> > +# Copyright (C) 2024 Intel Corporation
> > +
> > +obj-$(CONFIG_SPDM) += spdm.o
> > +
> > +spdm-y := core.o req-authenticate.o
> > diff --git a/lib/spdm/core.c b/lib/spdm/core.c
> > new file mode 100644
> > index 000000000000..f06402f6d127
> > --- /dev/null
> > +++ b/lib/spdm/core.c
> > @@ -0,0 +1,425 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * DMTF Security Protocol and Data Model (SPDM)
> > + * https://www.dmtf.org/dsp/DSP0274
> > + *
> > + * Core routines for message exchange, message transcript,
> > + * signature verification and session state lifecycle
> > + *
> > + * Copyright (C) 2021-22 Huawei
> > + * Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > + *
> > + * Copyright (C) 2022-24 Intel Corporation
> > + */
> > +
> > +#include "spdm.h"
> > +
> > +#include <linux/dev_printk.h>
> > +#include <linux/module.h>
> > +
> > +#include <crypto/hash.h>
> > +#include <crypto/public_key.h>
> > +
> > +static int spdm_err(struct device *dev, struct spdm_error_rsp *rsp)
>
> This approach to error singnaling looks unprecedented, and not in a good
> way. I like the idea of a SPDM-error-code to errno converter, and
> separate SPDM-error-code to error string, but not an SPDM-error-code to
> errno conversion that has a log emitting side effect.
That's fair. Using a common static const array of structs with string
and error code would also make this pair more readable by concentrating
the error code in one place.
>
> Would this not emit ambiguous messages like:
>
> cxl_pci 0000:35:00.0: Unexpected request
>
> How does I know that error message is from CXL SPDM functionality and
> not some other part of the driver?
>
> What if the SPDM authentication is optional, how does the consumer of
> this library avoid log spam? What about rate limiting?
>
> Did you consider leaving all error logging to the caller?
Problem there is that we've typically lost information because
of conversion to a smaller set of errno.
>
> I have less problem if these all become dev_dbg() or tracepoints, but
> dev_err() seems awkward.
dev_dbg() seems like an easy solution to me. Maybe add tracepoints
later...
>
> > +{
> > + switch (rsp->error_code) {
> > + case SPDM_INVALID_REQUEST:
> > + dev_err(dev, "Invalid request\n");
> > + return -EINVAL;
> > + case SPDM_INVALID_SESSION:
> > + if (rsp->version == 0x11) {
> > + dev_err(dev, "Invalid session %#x\n", rsp->error_data);
> > + return -EINVAL;
> > + }
> > + break;
> > + case SPDM_BUSY:
> > + dev_err(dev, "Busy\n");
> > + return -EBUSY;
> > + case SPDM_UNEXPECTED_REQUEST:
> > + dev_err(dev, "Unexpected request\n");
> > + return -EINVAL;
> > + case SPDM_UNSPECIFIED:
> > + dev_err(dev, "Unspecified error\n");
> > + return -EINVAL;
> > + case SPDM_DECRYPT_ERROR:
> > + dev_err(dev, "Decrypt error\n");
> > + return -EIO;
> > + case SPDM_UNSUPPORTED_REQUEST:
> > + dev_err(dev, "Unsupported request %#x\n", rsp->error_data);
> > + return -EINVAL;
> > + case SPDM_REQUEST_IN_FLIGHT:
> > + dev_err(dev, "Request in flight\n");
> > + return -EINVAL;
> > + case SPDM_INVALID_RESPONSE_CODE:
> > + dev_err(dev, "Invalid response code\n");
> > + return -EINVAL;
> > + case SPDM_SESSION_LIMIT_EXCEEDED:
> > + dev_err(dev, "Session limit exceeded\n");
> > + return -EBUSY;
> > + case SPDM_SESSION_REQUIRED:
> > + dev_err(dev, "Session required\n");
> > + return -EINVAL;
> > + case SPDM_RESET_REQUIRED:
> > + dev_err(dev, "Reset required\n");
> > + return -ECONNRESET;
> > + case SPDM_RESPONSE_TOO_LARGE:
> > + dev_err(dev, "Response too large\n");
> > + return -EINVAL;
> > + case SPDM_REQUEST_TOO_LARGE:
> > + dev_err(dev, "Request too large\n");
> > + return -EINVAL;
> > + case SPDM_LARGE_RESPONSE:
> > + dev_err(dev, "Large response\n");
> > + return -EMSGSIZE;
> > + case SPDM_MESSAGE_LOST:
> > + dev_err(dev, "Message lost\n");
> > + return -EIO;
> > + case SPDM_INVALID_POLICY:
> > + dev_err(dev, "Invalid policy\n");
> > + return -EINVAL;
> > + case SPDM_VERSION_MISMATCH:
> > + dev_err(dev, "Version mismatch\n");
> > + return -EINVAL;
> > + case SPDM_RESPONSE_NOT_READY:
> > + dev_err(dev, "Response not ready\n");
> > + return -EINPROGRESS;
> > + case SPDM_REQUEST_RESYNCH:
> > + dev_err(dev, "Request resynchronization\n");
> > + return -ECONNRESET;
> > + case SPDM_OPERATION_FAILED:
> > + dev_err(dev, "Operation failed\n");
> > + return -EINVAL;
> > + case SPDM_NO_PENDING_REQUESTS:
> > + return -ENOENT;
> > + case SPDM_VENDOR_DEFINED_ERROR:
> > + dev_err(dev, "Vendor defined error\n");
> > + return -EINVAL;
> > + }
> > +
> > + dev_err(dev, "Undefined error %#x\n", rsp->error_code);
> > + return -EINVAL;
> > +}
> > +
> > +/**
> > + * spdm_exchange() - Perform SPDM message exchange with device
> > + *
> > + * @spdm_state: SPDM session state
> > + * @req: Request message
> > + * @req_sz: Size of @req
> > + * @rsp: Response message
> > + * @rsp_sz: Size of @rsp
> > + *
> > + * Send the request @req to the device via the @transport in @spdm_state and
> > + * receive the response into @rsp, respecting the maximum buffer size @rsp_sz.
> > + * The request version is automatically populated.
> > + *
> > + * Return response size on success or a negative errno. Response size may be
> > + * less than @rsp_sz and the caller is responsible for checking that. It may
> > + * also be more than expected (though never more than @rsp_sz), e.g. if the
> > + * transport receives only dword-sized chunks.
> > + */
> > +ssize_t spdm_exchange(struct spdm_state *spdm_state,
> > + void *req, size_t req_sz, void *rsp, size_t rsp_sz)
> > +{
> > + struct spdm_header *request = req;
> > + struct spdm_header *response = rsp;
> > + ssize_t rc, length;
>
> What's the locking assumption with this public function? I see that the
> internal to this file usages wrap it in the state lock. Should that
> assumption be codified with a:
>
> lockdep_assert_held(&spdm_state->lock)
Seems reasonable to scatter those around.
>
> ?
>
> Or can this function be marked static?
Not without collapsing the various files into one.
>
> > +
> > + if (req_sz < sizeof(struct spdm_header) ||
> > + rsp_sz < sizeof(struct spdm_header))
> > + return -EINVAL;
> > +
> > + request->version = spdm_state->version;
> > +
> > + rc = spdm_state->transport(spdm_state->transport_priv, spdm_state->dev,
> > + req, req_sz, rsp, rsp_sz);
> > + if (rc < 0)
> > + return rc;
> > +
> > + length = rc;
> > + if (length < sizeof(struct spdm_header))
> > + return length; /* Truncated response is handled by callers */
> > +
> > + if (response->code == SPDM_ERROR)
> > + return spdm_err(spdm_state->dev, (struct spdm_error_rsp *)rsp);
> > +
> > + if (response->code != (request->code & ~SPDM_REQ)) {
> > + dev_err(spdm_state->dev,
> > + "Response code %#x does not match request code %#x\n",
> > + response->code, request->code);
> > + return -EPROTO;
> > + }
> > +
> > + return length;
> > +}
...
> > +
> > +/**
> > + * spdm_free_transcript() - Free transcript buffer
> > + *
> > + * @spdm_state: SPDM session state
> > + *
> > + * Free the transcript buffer after performing authentication. Reset the
> > + * pointer to the current end of transcript as well as the allocation size.
> > + */
> > +void spdm_free_transcript(struct spdm_state *spdm_state)
> > +{
> > + kvfree(spdm_state->transcript);
> > + spdm_state->transcript_end = NULL;
> > + spdm_state->transcript_max = 0;
>
> Similar locking context with public functions concern, but also the
> cleverness of why it is ok to not set ->transcript to NULL that really
> only hold true if spdm_append_transcript() and and
> spdm_free_transcript() are guaranteed to be serialized.
If there is any concurrency risk things have gone very very wrong.
However maybe it's worth adding locking/markings just to make that clear.
Any contention will make the transcript garbage but nothing
stops us making that explicit rather that relying on callers doing
the right thing.
>
> > +}
> > +/**
> > + * spdm_verify_signature() - Verify signature against leaf key
> > + *
> > + * @spdm_state: SPDM session state
> > + * @spdm_context: SPDM context (used to create combined_spdm_prefix)
> > + *
> > + * Implementation of the abstract SPDMSignatureVerify() function described in
> > + * SPDM 1.2.0 section 16: Compute the hash over @spdm_state->transcript and
> > + * verify that the signature at the end of the transcript was generated by
> > + * @spdm_state->leaf_key. Hashing the entire transcript allows detection
> > + * of message modification by a man-in-the-middle or media error.
> > + *
> > + * Return 0 on success or a negative errno.
> > + */
> > +int spdm_verify_signature(struct spdm_state *spdm_state,
> > + const char *spdm_context)
> > +{
> > + struct public_key_signature sig = {
> > + .s = spdm_state->transcript_end - spdm_state->sig_len,
> > + .s_size = spdm_state->sig_len,
> > + .encoding = spdm_state->base_asym_enc,
> > + .hash_algo = spdm_state->base_hash_alg_name,
> > + };
> > + u8 *mhash __free(kfree) = NULL;
> > + u8 *m __free(kfree);
> > + int rc;
> > +
> > + m = kmalloc(SPDM_COMBINED_PREFIX_SZ + spdm_state->hash_len, GFP_KERNEL);
>
> I am not a fan of forward declared scoped-based resource management
> variables [1], although PeterZ never responded to those suggestions.
>
> [1]: http://lore.kernel.org/171175585714.2192972.12661675876300167762.stgit@dwillia2-xfh.jf.intel.com
>
Agreed this is better as
u8 *m __free(kfree) =
kmalloc(SPDM_COMBINED_PREFIX_SZ + spdm_state->hash_len, GFP_KERNEL);
> > + if (!m)
> > + return -ENOMEM;
> > +
> > + /* Hash the transcript (sans trailing signature) */
> > + rc = crypto_shash_digest(spdm_state->desc, spdm_state->transcript,
> > + (void *)sig.s - spdm_state->transcript,
> > + m + SPDM_COMBINED_PREFIX_SZ);
> > + if (rc)
> > + return rc;
> > +
> > + if (spdm_state->version <= 0x11) {
> > + /*
> > + * SPDM 1.0 and 1.1 compute the signature only over the hash
> > + * (SPDM 1.0.0 section 4.9.2.7).
> > + */
> > + sig.digest = m + SPDM_COMBINED_PREFIX_SZ;
> > + sig.digest_size = spdm_state->hash_len;
> > + } else {
> > + /*
> > + * From SPDM 1.2, the hash is prefixed with spdm_context before
> > + * computing the signature over the resulting message M
> > + * (SPDM 1.2.0 sec 15).
> > + */
> > + spdm_create_combined_prefix(spdm_state->version, spdm_context,
> > + m);
> > +
> > + /*
> > + * RSA and ECDSA algorithms require that M is hashed once more.
> > + * EdDSA and SM2 algorithms omit that step.
> > + * The switch statement prepares for their introduction.
> > + */
> > + switch (spdm_state->base_asym_alg) {
> > + default:
and
u8 *mhash __free(kfree) =
kmalloc(spdm_state->hash_len, GFP_KERNEL);
With added bonus that the scope is reduced for this one.
You probably want to add explicit scope though with {} around the case block
so it's more obvious what the scope is.
> > + mhash = kmalloc(spdm_state->hash_len, GFP_KERNEL);
> > + if (!mhash)
> > + return -ENOMEM;
> > +
> > + rc = crypto_shash_digest(spdm_state->desc, m,
> > + SPDM_COMBINED_PREFIX_SZ + spdm_state->hash_len,
> > + mhash);
> > + if (rc)
> > + return rc;
> > +
> > + sig.digest = mhash;
> > + sig.digest_size = spdm_state->hash_len;
> > + break;
> > + }
> > + }
next prev parent reply other threads:[~2024-07-18 11:42 UTC|newest]
Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-30 19:35 [PATCH v2 00/18] PCI device authentication Lukas Wunner
2024-06-30 19:36 ` [PATCH v2 01/18] X.509: Make certificate parser public Lukas Wunner
2024-07-10 2:46 ` Alistair Francis
2024-06-30 19:37 ` [PATCH v2 02/18] X.509: Parse Subject Alternative Name in certificates Lukas Wunner
2024-07-10 2:48 ` Alistair Francis
2024-06-30 19:38 ` [PATCH v2 03/18] X.509: Move certificate length retrieval into new helper Lukas Wunner
2024-07-10 2:49 ` Alistair Francis
2024-07-18 11:04 ` Jonathan Cameron
2024-06-30 19:39 ` [PATCH v2 04/18] certs: Create blacklist keyring earlier Lukas Wunner
2024-07-10 2:52 ` Alistair Francis
2024-06-30 19:40 ` [PATCH v2 05/18] crypto: akcipher - Support more than one signature encoding Lukas Wunner
2024-06-30 19:41 ` [PATCH v2 06/18] crypto: ecdsa - Support P1363 " Lukas Wunner
2024-06-30 22:10 ` Herbert Xu
2024-07-29 14:27 ` Lukas Wunner
2024-06-30 19:42 ` [PATCH v2 07/18] spdm: Introduce library to authenticate devices Lukas Wunner
2024-06-30 21:29 ` Jeff Johnson
2024-07-08 9:57 ` Alexey Kardashevskiy
2024-07-08 12:54 ` Lukas Wunner
2024-07-09 0:45 ` Alexey Kardashevskiy
2024-07-09 8:49 ` Lukas Wunner
2024-07-09 5:09 ` Dan Williams
2024-07-18 11:42 ` Jonathan Cameron [this message]
2024-07-09 15:00 ` Jeff Johnson
2024-07-18 14:24 ` Jonathan Cameron
2024-06-30 19:43 ` [PATCH v2 08/18] PCI/CMA: Authenticate devices on enumeration Lukas Wunner
2024-07-09 18:10 ` Dan Williams
2024-07-09 19:32 ` Lukas Wunner
2024-07-09 23:31 ` Dan Williams
2024-07-11 15:00 ` Lukas Wunner
2024-07-11 17:50 ` Dan Williams
2024-07-12 0:50 ` Damien Le Moal
2024-07-14 8:42 ` Lukas Wunner
2024-07-15 17:21 ` Kees Cook
2024-07-15 18:12 ` Jason Gunthorpe
2024-07-15 20:36 ` Dan Williams
2024-07-15 22:02 ` Jason Gunthorpe
2024-07-15 22:17 ` Damien Le Moal
2024-07-15 23:03 ` Jason Gunthorpe
2024-07-15 23:26 ` Damien Le Moal
2024-07-15 23:42 ` Jason Gunthorpe
2024-07-15 23:57 ` Damien Le Moal
2024-07-16 0:11 ` Jason Gunthorpe
2024-07-16 1:23 ` Dan Williams
2024-07-15 22:50 ` Dan Williams
2024-07-15 23:21 ` Jason Gunthorpe
2024-07-15 23:37 ` Dan Williams
2024-07-15 23:55 ` Jason Gunthorpe
2024-07-16 1:35 ` Dan Williams
2024-07-22 10:19 ` Alexey Kardashevskiy
2024-07-22 12:06 ` Jason Gunthorpe
2024-07-23 4:26 ` Alexey Kardashevskiy
2024-07-23 12:58 ` Jason Gunthorpe
2024-07-15 20:19 ` Dan Williams
2024-07-15 20:08 ` Dan Williams
2024-06-30 19:44 ` [PATCH v2 09/18] PCI/CMA: Validate Subject Alternative Name in certificates Lukas Wunner
2024-07-10 20:35 ` Dan Williams
2024-06-30 19:45 ` [PATCH v2 10/18] PCI/CMA: Reauthenticate devices on reset and resume Lukas Wunner
2024-07-10 3:40 ` Alistair Francis
2024-07-10 23:23 ` Dan Williams
2024-07-18 15:01 ` Jonathan Cameron
2024-06-30 19:46 ` [PATCH v2 11/18] PCI/CMA: Expose in sysfs whether devices are authenticated Lukas Wunner
2024-07-17 23:17 ` Dan Williams
2024-07-18 15:11 ` Jonathan Cameron
2024-06-30 19:47 ` [PATCH v2 12/18] PCI/CMA: Expose certificates in sysfs Lukas Wunner
2024-07-18 2:43 ` Dan Williams
2024-07-18 15:16 ` Jonathan Cameron
2024-07-18 15:19 ` Jonathan Cameron
2024-06-30 19:48 ` [PATCH v2 13/18] sysfs: Allow bin_attributes to be added to groups Lukas Wunner
2024-07-04 10:13 ` Greg Kroah-Hartman
2024-07-12 3:49 ` Alistair Francis
2024-07-18 15:22 ` Jonathan Cameron
2024-06-30 19:49 ` [PATCH v2 14/18] sysfs: Allow symlinks to be added between sibling groups Lukas Wunner
2024-07-04 10:14 ` Greg Kroah-Hartman
2024-07-18 15:36 ` Jonathan Cameron
2024-06-30 19:50 ` [PATCH v2 15/18] PCI/CMA: Expose a log of received signatures in sysfs Lukas Wunner
2024-07-18 15:56 ` Jonathan Cameron
2024-06-30 19:51 ` [PATCH v2 16/18] spdm: Limit memory consumed by log of received signatures Lukas Wunner
2024-07-18 16:03 ` Jonathan Cameron
2024-06-30 19:52 ` [PATCH v2 17/18] spdm: Authenticate devices despite invalid certificate chain Lukas Wunner
2024-07-18 16:08 ` Jonathan Cameron
2024-06-30 19:53 ` [PATCH v2 18/18] spdm: Allow control of next requester nonce through sysfs Lukas Wunner
2024-07-18 16:11 ` Jonathan Cameron
2024-07-08 9:47 ` [PATCH v2 00/18] PCI device authentication Alexey Kardashevskiy
2024-07-08 13:35 ` Lukas Wunner
2025-02-11 1:30 ` Alexey Kardashevskiy
2025-02-12 16:36 ` Lukas Wunner
2025-05-20 8:35 ` Alexey Kardashevskiy
2025-05-29 5:29 ` Alexey Kardashevskiy
2025-05-29 9:40 ` Lukas Wunner
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=20240718124208.00002b72@Huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=aik@amd.com \
--cc=alistair.francis@wdc.com \
--cc=dan.j.williams@intel.com \
--cc=davem@davemloft.net \
--cc=david.e.box@intel.com \
--cc=dhaval.giani@amd.com \
--cc=dhowells@redhat.com \
--cc=dlemoal@kernel.org \
--cc=dwmw2@infradead.org \
--cc=ebiggers@google.com \
--cc=gdhanuskodi@nvidia.com \
--cc=graf@amazon.com \
--cc=helgaas@kernel.org \
--cc=herbert@gondor.apana.org.au \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=jgg@nvidia.com \
--cc=jglisse@google.com \
--cc=keyrings@vger.kernel.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=lukas@wunner.de \
--cc=ming4.li@intel.com \
--cc=pgonda@google.com \
--cc=sameo@rivosinc.com \
--cc=seanjc@google.com \
--cc=stefanb@linux.ibm.com \
--cc=wilfred.mallawa@wdc.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).