mbox series

[v4,0/3] Initial support for SPDM Responders

Message ID 20240213024403.1060188-1-alistair.francis@wdc.com (mailing list archive)
Headers show
Series Initial support for SPDM Responders | expand

Message

Alistair Francis Feb. 13, 2024, 2:44 a.m. UTC
The Security Protocol and Data Model (SPDM) Specification defines
messages, data objects, and sequences for performing message exchanges
over a variety of transport and physical media.
 - https://www.dmtf.org/sites/default/files/standards/documents/DSP0274_1.3.0.pdf

SPDM currently supports PCIe DOE and MCTP transports, but it can be
extended to support others in the future. This series adds
support to QEMU to connect to an external SPDM instance.

SPDM support can be added to any QEMU device by exposing a
TCP socket to a SPDM server. The server can then implement the SPDM
decoding/encoding support, generally using libspdm [1].

This is similar to how the current TPM implementation works and means
that the heavy lifting of setting up certificate chains, capabilities,
measurements and complex crypto can be done outside QEMU by a well
supported and tested library.

This series implements socket support and exposes SPDM for a NVMe device.

1: https://github.com/DMTF/libspdm

v4:
 - Rebase
v3:
 - Spelling fixes
 - Support for SPDM-Utils
v2:
 - Add cover letter
 - A few code fixes based on comments
 - Document SPDM-Utils
 - A few tweaks and clarifications to the documentation

Alistair Francis (1):
  hw/pci: Add all Data Object Types defined in PCIe r6.0

Huai-Cheng Kuo (1):
  backends: Initial support for SPDM socket support

Wilfred Mallawa (1):
  hw/nvme: Add SPDM over DOE support

 docs/specs/index.rst         |   1 +
 docs/specs/spdm.rst          | 122 ++++++++++++++++++++
 include/hw/pci/pci_device.h  |   5 +
 include/hw/pci/pcie_doe.h    |   5 +
 include/sysemu/spdm-socket.h |  44 +++++++
 backends/spdm-socket.c       | 216 +++++++++++++++++++++++++++++++++++
 hw/nvme/ctrl.c               |  53 +++++++++
 backends/Kconfig             |   4 +
 backends/meson.build         |   2 +
 9 files changed, 452 insertions(+)
 create mode 100644 docs/specs/spdm.rst
 create mode 100644 include/sysemu/spdm-socket.h
 create mode 100644 backends/spdm-socket.c

Comments

Jonathan Cameron Feb. 15, 2024, 2:44 p.m. UTC | #1
On Tue, 13 Feb 2024 12:44:00 +1000
Alistair Francis <alistair23@gmail.com> wrote:

Hi All,

Just wanted to add that back in v2 Klaus Jensen stated:

"I have no problem with picking this up for nvme, but I'd rather not take
 the full series through my tree without reviews/acks from the pci
 maintainers."

So I'd like to add my request that Michael and/or Marcell takes a look
when they have time.

I've been carrying more or less the first 2 patches in my CXL staging
tree for a couple of years (the initial Linux Kernel support that Lukas
Wunner is now handling was developed against this) and I would love
to see this upstream. Along with PCI and CXL and NVME usecases this
is a major part of the Confidential Compute device assignment story
via PCI/TDISP and CXL equivalent.

It's not changed in significant ways since v2 back in October last year.

Thanks,

Jonathan

> The Security Protocol and Data Model (SPDM) Specification defines
> messages, data objects, and sequences for performing message exchanges
> over a variety of transport and physical media.
>  - https://www.dmtf.org/sites/default/files/standards/documents/DSP0274_1.3.0.pdf
> 
> SPDM currently supports PCIe DOE and MCTP transports, but it can be
> extended to support others in the future. This series adds
> support to QEMU to connect to an external SPDM instance.
> 
> SPDM support can be added to any QEMU device by exposing a
> TCP socket to a SPDM server. The server can then implement the SPDM
> decoding/encoding support, generally using libspdm [1].
> 
> This is similar to how the current TPM implementation works and means
> that the heavy lifting of setting up certificate chains, capabilities,
> measurements and complex crypto can be done outside QEMU by a well
> supported and tested library.
> 
> This series implements socket support and exposes SPDM for a NVMe device.
> 
> 1: https://github.com/DMTF/libspdm
> 
> v4:
>  - Rebase
> v3:
>  - Spelling fixes
>  - Support for SPDM-Utils
> v2:
>  - Add cover letter
>  - A few code fixes based on comments
>  - Document SPDM-Utils
>  - A few tweaks and clarifications to the documentation
> 
> Alistair Francis (1):
>   hw/pci: Add all Data Object Types defined in PCIe r6.0
> 
> Huai-Cheng Kuo (1):
>   backends: Initial support for SPDM socket support
> 
> Wilfred Mallawa (1):
>   hw/nvme: Add SPDM over DOE support
> 
>  docs/specs/index.rst         |   1 +
>  docs/specs/spdm.rst          | 122 ++++++++++++++++++++
>  include/hw/pci/pci_device.h  |   5 +
>  include/hw/pci/pcie_doe.h    |   5 +
>  include/sysemu/spdm-socket.h |  44 +++++++
>  backends/spdm-socket.c       | 216 +++++++++++++++++++++++++++++++++++
>  hw/nvme/ctrl.c               |  53 +++++++++
>  backends/Kconfig             |   4 +
>  backends/meson.build         |   2 +
>  9 files changed, 452 insertions(+)
>  create mode 100644 docs/specs/spdm.rst
>  create mode 100644 include/sysemu/spdm-socket.h
>  create mode 100644 backends/spdm-socket.c
>
Klaus Jensen Feb. 16, 2024, 8:51 a.m. UTC | #2
On Feb 15 14:44, Jonathan Cameron wrote:
> On Tue, 13 Feb 2024 12:44:00 +1000
> Alistair Francis <alistair23@gmail.com> wrote:
> 
> Hi All,
> 
> Just wanted to add that back in v2 Klaus Jensen stated:
> 
> "I have no problem with picking this up for nvme, but I'd rather not take
>  the full series through my tree without reviews/acks from the pci
>  maintainers."
> 
> So I'd like to add my request that Michael and/or Marcell takes a look
> when they have time.
> 
> I've been carrying more or less the first 2 patches in my CXL staging
> tree for a couple of years (the initial Linux Kernel support that Lukas
> Wunner is now handling was developed against this) and I would love
> to see this upstream. Along with PCI and CXL and NVME usecases this
> is a major part of the Confidential Compute device assignment story
> via PCI/TDISP and CXL equivalent.
> 
> It's not changed in significant ways since v2 back in October last year.
> 

Would someone be willing to sign up to maintain the spdm_socket backend?
Alistair Francis Feb. 16, 2024, 10:44 a.m. UTC | #3
On Fri, Feb 16, 2024 at 6:52 PM Klaus Jensen <its@irrelevant.dk> wrote:
>
> On Feb 15 14:44, Jonathan Cameron wrote:
> > On Tue, 13 Feb 2024 12:44:00 +1000
> > Alistair Francis <alistair23@gmail.com> wrote:
> >
> > Hi All,
> >
> > Just wanted to add that back in v2 Klaus Jensen stated:
> >
> > "I have no problem with picking this up for nvme, but I'd rather not take
> >  the full series through my tree without reviews/acks from the pci
> >  maintainers."
> >
> > So I'd like to add my request that Michael and/or Marcell takes a look
> > when they have time.
> >
> > I've been carrying more or less the first 2 patches in my CXL staging
> > tree for a couple of years (the initial Linux Kernel support that Lukas
> > Wunner is now handling was developed against this) and I would love
> > to see this upstream. Along with PCI and CXL and NVME usecases this
> > is a major part of the Confidential Compute device assignment story
> > via PCI/TDISP and CXL equivalent.
> >
> > It's not changed in significant ways since v2 back in October last year.
> >
>
> Would someone be willing to sign up to maintain the spdm_socket backend?

I'm happy to and should have already edited MAINTAINERS to indicate
that. I'll fix that up in the next version

Alistair