> On 1 Jun 2026, at 5:02 PM, Abhisek Panda <[email protected]> wrote: > > > >> On 28 May 2026, at 4:42 PM, Peter Krempa <[email protected]> wrote: >> >> !-------------------------------------------------------------------| >> CAUTION: External Email >> >> |-------------------------------------------------------------------! >> >> On Thu, May 28, 2026 at 09:45:11 +0000, Tejus GK wrote: >>> >>>> >>>>> 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. >>> >>> >>> Hi Peter, thank you for the response! >>> For the above, we indeed meant it for the non P2P migration mode, >>> So since the 2 libvirts aren’t talking to each other in this case, the >>> client, must inform the destination libvirt on >>> what the PSK is, and in turn for that, the src libvirt must inform the >>> client what the PSK is. >> >> Actually the client library doesn't have to do anything. The PSK would >> be generated by the source libvirt daemon and put into the migration >> cookie. The client handling the migration needs to handle the cookie >> anyways, so that is for free. >> >> The setup would also work out of the box (if both daemons are new >> enough) which would allow us to actually enable TLS by default. >> >> Obviously the client inbetween would get to see the PSK, but as >> explained in my previous reply, the client itself needs to have a >> connection with 'domain:write', 'domain:start' and 'domain:migrate' >> permission (if you'd be using ACLs) so the on-disk key can't really be >> protected from such client anyways. >> >> >>> I think all this would >>> have been much easier, if the client controls the lifecycle of the PSK. >> >> As said above I don't think that this is the case. In fact for any user >> it's the simplest if the PSK handling happens automagically without any >> setup. >> >>> >>> Even outside this scenario, handing over the the PSK lifecycle management >>> to the client provides >>> greater flexibility and control over PSK parameters such as its key size, >>> cryptographic algorithm, >> >> Agreed. We could add config options for these. >> >>> and rotation policies, >> >> Rotation policy doesn't make sense as an advantage because you don't >> ever get better than single-use keys. >> >>> which are indeed some aspects that clients may prefer to manage >>> according to their own security requirements, similar to what happens right >>> now in the x509 scenario. >> >> With this argument, for any client who really wants to deal with >> generating the PSK, it would IMO make more sense to have the PSK as a >> virSecret and use it for a single VM. >> >> Storing them as keys is IMO inflexible and actually much worse than the >> x509 setup because you can't invalidate access to a single (e.g. >> compromised key) without rekeying everything with a completely shared >> PSK. > > Hi Peter, > > Thank you for the input. We're working on a revised design based on your > recommendations and will share the update soon. > > Thanks > Abhisek Panda > >
Hi Peter, I have re-architected the support for enabling the TLS-PSK-based encrypted migration in Libvirt. In this design, Libvirt handles the lifecycle of pre-shared keys, managing their generation, persistent storage, and cleanup. We propose the following changes to Libvirt. 1. Add the following configuration attributes: "migrate_base_psk_dir" and "migrate_psk_length" to qemu.conf. This allows users to define the base directory containing the generated pre-shared keys and the size of the pre-shared key in bytes. Note: The default value of "migrate_base_psk_dir" is set to "/var/run/libvirt/qemu" and "migrate_psk_length" is set to "32". 2. Introduce a new migration flag VIR_MIGRATE_TLS_PSK, that enables the use of TLS-PSK-based authentication mechanism for an encrypted migration session. 3. If the VIR_MIGRATE_TLS_PSK flag is set, Libvirt generates a random key of "migrate_psk_length" bytes on the source, and embeds it within a new <migration-key> element inside the migration cookie. Subsequently, it writes this key into a file located at <migrate_base_psk_dir>/<vm_uuid>/keys.psk with the following contents: qemu:<generated_key>. 4. The destination Libvirt reads the key from <migration-key> in the incoming cookie. Subsequently, it writes the key into a file located in <migrate_base_psk_dir>/<vm_uuid>/keys.psk with the same content as in step-3. 5. During the perform stage, Libvirt creates the tls-creds-psk QEMU object with the appropriate attributes for enabling encrypted migration. 6. Upon migration completion and on all failure/abort paths, Libvirt deletes the <migrate_base_psk_dir>/<vm_uuid> directory, thereby ensuring no key specific information is present on the disk. Thinking more about this workflow, a client might also utilise an existing PSK stored as a libvirt secret. So, we decided to bake that support in our patches too. In case the user wants to use an existing secret for a migration session, we extend the design with a new migration parameter: "VIR_MIGRATE_PARAM_TLS_PSK_SECRET_UUID". In this workflow, a user can initialise the pre-shared key as the secret payload. Libvirt is then provided the secret UUID using the "VIR_MIGRATE_PARAM_TLS_PSK_SECRET_UUID" migration parameter. In this case, Libvirt reads the required PSK via lookup of the secret API and utilizes for encrypting the migration stream, skipping the auto generation step entirely. I plan to send the v2 of the patch series along with the support for providing the pre-shared key to Libvirt using the secret UUID later this week. Looking forward to your reviews.
