On Fri, Jul 18, 2025 at 13:05:33 +0100, Daniel P. Berrangé via Devel wrote:
From: Daniel P. Berrangé <berrange@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é <berrange@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 <pkrempa@redhat.com>