Your email client (MUA) seems to be breaking quoting in the email, because parts of my reply look like text you wrote in your reply which makes it very hard to follow your conversation.
On Thu, May 28, 2026 at 08:13:40 +0000, Abhisek Panda wrote: > > > 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 The libvirt connection has to be considered secure, as otherwise you'd be leaking the credentials allowing anyone to have the same effective access as the system connection to your hypervisor (effectively allowing them to run processes as root.) Basically the connection is either secured by the SSH transport or the TLS transport. If you use anything else you have bigger problems than leaking the migration PSK. > 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. Due to the above this sentence doesn't make much sense. > 2. In a managed direct migration workflow, an intermediary client brokers the > connection between > the source and destination. What do you mean by this? How is it brokered? Which part of the conenction? Do you mean the non-P2P migration mode? (which is the only case where the migration cookie wouldn't go directly from the source libvirtd/virtqemud to the destination libvirt/virtqemud) That one is secured by the connection transport mentioned above. > 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. So IMO this point doesn't make sense either.
