Re: [RFC v1 0/3] Initial support for SPDM

[Alistair Francis <alistair23@gmail.com>]

On Wed, Aug 9, 2023 at 8:11 AM Jonathan Cameron
<Jonathan.Cameron@huawei.com> wrote:
>
> On Tue,  8 Aug 2023 11:51:21 -0400
> Alistair Francis <alistair23@gmail.com> wrote:
>
> > 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
> >
> > This series is a very initial start on adding SPDM support to QEMU.
> >
> > This series uses libspdm [1] which is a reference implementation of
> > SPDM.
> >
> > The series starts by adding support for building and linking with
> > libspdm. It then progresses to handling SPDM requests in the NVMe device
> > over the PCIe DOE protocol.
> >
> > This is a very early attempt. The code quality is not super high, the C
> > code hasn't been tested at all. This is really just an RFC to see if
> > QEMU will accept linking with libspdm.
> >
> > So, the main question is, how do people feel about linking with libspdm
> > to support SPDM?
> >
> > 1: https://github.com/DMTF/libspdm
>
> Hi Alastair,
>
> For reference / background we've had SPDM support for CXL emulated devices
> in our staging tree for quite a while - it's not upstream because of
> exactly this question (+ no one had upstreaming this as a high priority
> as out of tree was fine for developing the kernel stack - it's well
> isolated in the code so there was little cost in rebasing this feature)
> - and because libspdm is packaged by almost no one. There were problems
> building it with external crypto libraries etc.

Thanks for pointing that out! I didn't realise there was existing QEMU
work. I'm glad others are looking into it

Building with libspdm is difficult. Even this series does have weird
issues with openssl's crypto library. I have been working towards
packaging libspdm into buildroot, which has helped cleanup libspdm to
be more user friendly. libspdm 3.0 for example is now a lot easier to
build/package, but I expect to continue to improve things.

There will need to be more improvements to libspdm before this series
could be merged.

>
> Looks like you have had a lot more success than I ever did in getting that
> to work. I tried a few times in the past and ended up sticking with
> the Avery design folks approach of a socket connection to spdm-emu
> Given you cc'd them I'm guessing you came across that work which is what
> we used for testing the kernel code Lukas is working on currently.
>
> https://lore.kernel.org/qemu-devel/20210629132520.00000d1f@Huawei.com/
>
> https://gitlab.com/jic23/qemu/-/commit/9864fb29979e55c1e37c20edf00907d9524036e8

Thanks for that!

In the past the QEMU community has refused to accept upstream changes
that expose QEMU internals via sockets. So I suspect linking with
libspdm will be a more upstreamable approach.

On top of that requiring user to run an external socket application is clunky.

>
> So I think we have 2 choices here.
> 1) Do what you have done and build the library as you are doing.
>  - Can fix a version - so don't care if they change the ABI etc other
>    than needing to move the version QEMU uses forwards when we need
>    to for new features.

I agree

>  - Cert management is going to add a lot of complexity into QEMU.
>    I've not looked at how much infrastructure we can reuse from elsewhere.
>    Maybe this is a solved problem.

Could we not just point to a cert when running QEMU?

>
> 2) Keep the SPDM emulation external.
>  - I'm not sure the socket protocol used by spdm-emu is fixed in stone
>    as people tend to change both ends.
>  - Cert management and protocol options etc are already available.

I suspect this will never get upstream though. My aim is to get
something upstream, so this is probably a no go (unless someone jumps
in and says this is ok).

>
> Personally I prefer the control option 1 gives us, even if it's a lot more
> code.  Option 2 also rather limits our ability to do anything with
> the encrypted data as well. It's fine if the aim is just verification
> of simple flows, but if we need to inject particular measurements etc
> it doesn't really work.

I like option 1 as well :)

I don't envisage QEMU supporting extremely complex flows. I was more
aiming for a certificate and some measurement data and maybe a
manifest. My hope was basic SPDM support, not a complete test suite.

Alistair

>
> Jonathan
>
>
>
> >
> > Alistair Francis (3):
> >   subprojects: libspdm: Initial support
> >   hw: nvme: ctrl: Initial support for DOE
> >   hw: nvme: ctrl: Process SPDM requests
> >
> >  meson.build                   | 78 +++++++++++++++++++++++++++++++++++
> >  hw/nvme/nvme.h                |  4 ++
> >  include/hw/pci/pcie_doe.h     |  1 +
> >  hw/nvme/ctrl.c                | 35 ++++++++++++++++
> >  .gitmodules                   |  3 ++
> >  meson_options.txt             |  3 ++
> >  scripts/meson-buildoptions.sh |  3 ++
> >  subprojects/.gitignore        |  1 +
> >  subprojects/libspdm.wrap      |  5 +++
> >  9 files changed, 133 insertions(+)
> >  create mode 100644 subprojects/libspdm.wrap
> >
>