On 27 May 2026, at 3:30 PM, Peter Krempa <[email protected]> wrote:
!-------------------------------------------------------------------| CAUTION: External Email |-------------------------------------------------------------------! On Wed, May 27, 2026 at 09:17:27 +0000, Abhisek Panda wrote: For encrypted migration of VMs, QEMU provides the TLS-PSK authentication apart from TLS certificates. This mechanism relies on pre-shared keys (a secret key that is known to both sender and receiver prior to secure communication) for providing secure transfer of data. We store these keys in a pre-shared key file, where each line contains a pair of identifier and its corresponding key. During an encrypted migration, the parties negotiate which unique identifier to utilize, then parse the key file to extract the key matching the identifier. Add the "migrate_tls_psk_dir" parameter to qemu.conf to allow users to define the path containing the pre-shared keys. In case the user does not define this parameter and attempts to utilize TLS-PSK for migration, we fallback to the configurable "default_tls_psk_dir" parameter whose value is set to /etc/pki/qemu-psk by default. In addition, we get the client identity by parsing the migration URI, defaulting to 'qemu' if username is undefined. Example entry format in a PSK file: qemu:61aa7b2c93d4e8f10c25b6a782e3f4051a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d Suggested-by: Tejus GK <[email protected]> Signed-off-by: Abhisek Panda <[email protected]> --- src/qemu/libvirtd_qemu.aug | 2 ++ src/qemu/qemu.conf.in | 19 +++++++++++ src/qemu/qemu_conf.c | 55 +++++++++++++++++++++++++++++- src/qemu/qemu_conf.h | 3 ++ src/qemu/qemu_migration.c | 2 ++ src/qemu/test_libvirtd_qemu.aug.in | 2 ++ tests/testutilsqemu.c | 2 ++ 7 files changed, 84 insertions(+), 1 deletion(-) [...] +# Use of TLS-PSK requires the pre-shared key files to be present. +# The default is to keep them in /etc/pki/qemu-psk. This directory must contain +# keys.psk - PSK key information +# +# If the directory does not exist, libvirtd will fail to start. If the +# directory doesn't contain the necessary files, VM migration will fail +# during TLS handshake if they are configured to use TLS-PSK. +# +#default_tls_psk_dir = "/etc/pki/qemu-psk" + + What is the point of having a global directory for the PSK keys? Since the can be transient, libvirt could simply generate a random key before the migration, write it to a file (IIUC there's no way to load it from the monitor via an encrypted secret?) and use that. Just for the one migration with absolutely no setup needed from the user. That way you could avoid all this setup and make migrations work with TLS out of the box, and the secret itself would be transported in the migration cookie. In this design of creating a symmetric key at the source using the libvirt and sharing it with the destination using the migration cookie has the following concerns that lead to the use of a global directory for the PSK keys: 1. Transmitting the key via the migration cookie requires a strictly secure communication channel between the source and destination libvirt instances. Conversely, utilizing a global directory for Pre-Shared Keys (PSKs) decouples key management from the control path, achieving the goal of encrypted migration data transfer without depending on the security of the libvirt communication channel. 2. In a managed direct migration workflow, an intermediary client brokers the connection between the source and destination. If the key is embedded within the migration cookie, this client gains full visibility into the secret, creating a significant attack surface within the system architecture.
