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