On Wed, Aug 9, 2023 at 8:11 AM Jonathan Cameron <jonathan.came...@huawei.com> wrote: > > On Tue, 8 Aug 2023 11:51:21 -0400 > Alistair Francis <alistai...@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.00000...@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 > > >
