On Fri, Jul 18, 2025 at 13:05:33 +0100, Daniel P. Berrangé via Devel wrote:
> From: Daniel P. Berrangé <[email protected]>
>
> 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é <[email protected]>
> ---
[...]
> 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 <[email protected]>
