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

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

-- 
2.41.0

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.

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

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

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.

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.

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
>

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

On Wed, 9 Aug 2023 12:45:35 -0400
Alistair Francis <alistair23@gmail.com> wrote:

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

Yes, but it's going to be multiple cert trees per PCI device with all the
association with particular SPDM instances etc. Not too bad I guess.

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

There is precedence with the TPM stuff using swtpm as the provider.
https://qemu.readthedocs.io/en/latest/specs/tpm.html#the-qemu-tpm-emulator-device

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

I do envision complex flows. Need to be able to do TDISP for the
confidential computing stuff (and other specs that aren't released yet).

Most of the interest we've had in SPDM in general has been to get things
up and running for that stuff.

Jonathan


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

On Thu, Aug 10, 2023 at 6:18 AM Jonathan Cameron
<Jonathan.Cameron@huawei.com> wrote:
>
> On Wed, 9 Aug 2023 12:45:35 -0400
> Alistair Francis <alistair23@gmail.com> wrote:
>
> > 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?
>
> Yes, but it's going to be multiple cert trees per PCI device with all the
> association with particular SPDM instances etc. Not too bad I guess.
>
> >
> > >
> > > 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).
>
> There is precedence with the TPM stuff using swtpm as the provider.
> https://qemu.readthedocs.io/en/latest/specs/tpm.html#the-qemu-tpm-emulator-device

Good point. I forgot about the TPM.

I have CCed Stefan in case they have any comments

>
> >
> > >
> > > 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.
>
> I do envision complex flows. Need to be able to do TDISP for the
> confidential computing stuff (and other specs that aren't released yet).
>
> Most of the interest we've had in SPDM in general has been to get things
> up and running for that stuff.

Hmmm.... That might be trickier to get with an inbuilt library.

Let's wait for feedback on this RFC and then go from there

Alistair

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