On Thu, Oct 17, 2024 at 10:37:21AM -0300, Ágatha Freitas wrote: > On Thu, Oct 17, 2024 at 7:00 AM Daniel P. Berrangé <berra...@redhat.com> > wrote: > > > On Thu, Oct 17, 2024 at 02:00:35PM +1000, Alistair Francis wrote: > > > On Thu, Oct 17, 2024 at 2:35 AM htafr <htafr...@gmail.com> wrote: > > > > > > > > (I) Summary > > > > > > =========================================================================== > > > > > > > > This patch is the beginning of the support of the Security Protocol and > > > > Data Model (SPDM). There are some known issues (see II), but it's > > > > usable and not many users are going to use this functionality for now, > > > > but for those who will it may facilitate the development. > > > > > > > > There are some people working with LibSPDM to implement the SPDM on > > > > emulated devices, however current works that use QEMU compile LibSPDM > > > > out-of-tree [1][2][3]. This patch enables the compilation of LibSPDM > > when > > > > user pass the parameter '--enable-libspdm' to configure file, this > > option > > > > is disabled by default. The following parameters were also added: > > > > > > > > --libspdm-crypto=CHOICE set LibSPDM crypto algorithm [mbedtls] > > (choices: > > > > mbedtls/openssl) > > > > --libspdm-toolchain=VALUE > > > > toolchain to use for LibSPDM compilation > > [GCC] > > > > > > > > In order to facilitate future code development using LibSPDM API, this > > > > patch also provides the definition of the macro 'CONFIG_LIBSPDM'. > > > > > > We have talked about this before, see > > > https://patchew.org/QEMU/cover.1691509717.git.alistair.fran...@wdc.com/ > > > > > > The general agreement seemed to be that it will be hard to do SPDM > > > configuration inside QEMU, hence the external library (like the QEMU > > > TPM support). > > > > More generally, seeing this libspdm proposed for QEMU, without any > > corresponding usage of it it dubious. It is hard to judge whether > > it makes any sense, without seeing how it will be used in real > > device code inside QEMU. > > > > Currently, I'm working with EDK2 and QEMU so I have a branch [1] with > ongoing > modifications in files backends/spdm.c and hw/nvme/auth.c. Although the > current > modifications are able to exchange SPDM messages, it's far from being > complete > and it's not following better code practices yet. I'm making use of > Alistair's and > Mallawa's previous work in NVMe to authenticate it through PCI [2]. > > [1] WIP: SPDM integration > Link: https://github.com/htafr/qemu/tree/libspdm-dev > [2] WIP: SPDM in OVMF > Link: https://github.com/htafr/edk2/tree/ovmf-spdm > > > > > > On the cryptography side, I'm not a fan of linking another > > crypto library to QEMU, that's different from what we already > > support in our crypto layer. openssl in particular is a problem > > due to its licensing - people tend to hand-waive away the > > licensing incompatibility by pretending openssl is a "system library" > > but I disagree with that interpretation. > > > > > > (II) Known Limitations > > > > > > =========================================================================== > > > > > > > > 1. This patch enables LibSPDM in-tree compilation for Linux systems > > only. > > > > 2. LibSPDM compilation uses CMake, so meson build system is making use > > > > of the CMake module [4]. > > > > 3. Some problems may occur when compiling LibSPDM with MbedTls such as: > > > > error: "_GNU_SOURCE" redefined [-Werror] > > > > 10 | #define _GNU_SOURCE > > > > > > > > It's possible to compile using --disable-werror. > > > > > > > > (III) Sample configuration > > > > > > =========================================================================== > > > > > > > > ../configure \ > > > > --disable-werror \ > > > > --enable-libspdm \ > > > > --libspdm-crypto=mbedtls \ > > > > --enable-gcov > > > > > > > > References: > > > > [1] riscv-spdm > > > > Link: https://github.com/htafr/riscv-spdm > > > > [2] spdm-benchmark > > > > Link: https://github.com/rcaalves/spdm-benchmark > > > > [3] qemu-spdm-emulation-guide > > > > Link: https://github.com/twilfredo/qemu-spdm-emulation-guide > > > > > > This one has been merged upstream and mainline QEMU supports it now: > > > > > > https://www.qemu.org/docs/master/specs/spdm.html > > > > So with that merged, is this proposal for linking to libspdm redundant ? > > > > I'm not sure if I understood the redundancy. Would it be against QEMU > practices > to have another openssl as well as mbedtls linked inside it?
QEMU doesn't link to either of those libraries. We preferentially use gnutls, with a fallback to gcrypt or nettle, to avoid the murky openssl licensing situation, and to a lesser extent because openssl has an unpleasant API to use. mbedtls isn't used because it is a more niche solution compared to what we already support, so wasn't compelling to support. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
