On Thu, Aug 10, 2023 at 6:18 AM Jonathan Cameron <jonathan.came...@huawei.com> wrote: > > 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
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 > > > > > > > >
