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