On Fri, Jul 18, 2025 at 13:05:33 +0100, Daniel P. Berrangé via Devel wrote: > From: Daniel P. Berrangé <berra...@redhat.com> > > QEMU will either use the GNUTLS default priority string of "NORMAL", > or on Fedora/RHEL related distros, "@QEMU,SYSTEM", which resolves to > a configuration in /etc/crypto-policies/back-ends/gnutls.config. > > The latter gives the sysadmin the ability to change the priority > string used for GNUTLS at deployment time, either system side, or > exclusively for QEMU, avoiding the hardcoded GNUTLS defaults. > > There are still some limitations to this: > > * Priorities cannot be set for different areas of QEMU > functionality (migration, vnc, nbd, etc) > > * Priorities are fixed at the time when QEMU first > triggers GNUTLS to load its config file, often > immediately at startup. > > We recently uncovered a QEMU bug that causes crashes in live > migration with TLS-1.3, where the easiest workaround is to > change the TLS priorities. We can't change this on the running > QEMU, but fortunately it is possible to change it on the target > QEMU and the TLS handshake will make it take effect on both > src and dst. > > The problem is, while fixing the immediate incoming and outgoing > live migration problems, the workaround will apply to everything > else that QEMU does for the rest of the time that process exists. > > We want to make it possible to set the TLS priorities only for > the current migrations, such that if the target QEMU has a fixed > GNUTLS, it will not have its TLS priorities hobbled for the next > live migration. > > To achieve this we need libvirt to be able to (optionally) set > the TLS priority string with QEMU. While live migration is the > most pressing need, the new qemu.conf parameters are wired up > for every subsystem for greater selectivity in future. > > With this we can activate the GNUTLS workaround for running > QEMU processes by editting qemu.conf and restarting virtqemud, > and later undo this the same way. > > Signed-off-by: Daniel P. Berrangé <berra...@redhat.com> > ---
[...] > diff --git a/tests/qemuxmlconftest.c b/tests/qemuxmlconftest.c > index 9fba984290..1b73e823ae 100644 > --- a/tests/qemuxmlconftest.c > +++ b/tests/qemuxmlconftest.c > @@ -1596,7 +1596,9 @@ mymain(void) > driver.config->nbdTLSx509secretUUID = > g_strdup("6fd3f62d-9fe7-4a4e-a869-7acd6376d8ea"); > DO_TEST_CAPS_LATEST("disk-network-tlsx509-nbd"); > DO_TEST_CAPS_VER_PARSE_ERROR("disk-network-tlsx509-nbd-hostname", > "6.2.0"); > + driver.config->nbdTLSpriority = g_strdup("@SYSTEM:-VERS-TLS1.3"); > DO_TEST_CAPS_LATEST("disk-network-tlsx509-nbd-hostname"); > + driver.config->nbdTLSpriority = NULL; Please use: g_clear_pointer(&driver.config->nbdTLSpriority, g_free) instead of leaking the pointer. I'll likely also break the ASAN CI job. > DO_TEST_CAPS_LATEST("disk-network-http"); > VIR_FREE(driver.config->nbdTLSx509secretUUID); > DO_TEST_CAPS_LATEST("disk-network-ssh"); > @@ -1729,8 +1731,10 @@ mymain(void) > driver.config->vncTLS = 1; > driver.config->vncTLSx509verify = 1; > DO_TEST_CAPS_LATEST("graphics-vnc-tls"); > + driver.config->vncTLSpriority = g_strdup("@SYSTEM:-VERS-TLS1.3"); > driver.config->vncTLSx509secretUUID = > g_strdup("6fd3f62d-9fe7-4a4e-a869-7acd6376d8ea"); > DO_TEST_CAPS_LATEST("graphics-vnc-tls-secret"); > + VIR_FREE(driver.config->vncTLSpriority); Or like this. > VIR_FREE(driver.config->vncTLSx509secretUUID); > driver.config->vncSASL = driver.config->vncTLSx509verify = > driver.config->vncTLS = 0; > DO_TEST_CAPS_LATEST("graphics-vnc-egl-headless"); > @@ -1880,7 +1884,9 @@ mymain(void) > driver.config->chardevTLSx509verify = 0; > DO_TEST_CAPS_LATEST("serial-tcp-tlsx509-chardev-notls"); > driver.config->chardevTLSx509secretUUID = > g_strdup("6fd3f62d-9fe7-4a4e-a869-7acd6376d8ea"); > + driver.config->chardevTLSpriority = g_strdup("@SYSTEM:-VERS-TLS1.3"); > DO_TEST_CAPS_LATEST("serial-tcp-tlsx509-secret-chardev"); > + VIR_FREE(driver.config->chardevTLSpriority); > VIR_FREE(driver.config->chardevTLSx509secretUUID); > driver.config->chardevTLS = 0; > DO_TEST_CAPS_LATEST("serial-many-chardev"); With the above nit fixed: Reviewed-by: Peter Krempa <pkre...@redhat.com>