On Wed, 9 Aug 2023 12:45:35 -0400 Alistair Francis <alistai...@gmail.com> wrote:
> 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? 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 > > > > >
