> On 16 Jun 2026, at 1:10 PM, Peter Krempa <[email protected]> wrote:
>
> !-------------------------------------------------------------------|
> CAUTION: External Email
>
> |-------------------------------------------------------------------!
>
> On Tue, Jun 16, 2026 at 08:22:08 +0100, Daniel P. Berrangé wrote:
>> On Tue, Jun 16, 2026 at 05:08:30AM +0000, Abhisek Panda wrote:
>>> 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".
>>
>> Note, PSKs should be treated as one-time-use keys that are generated
>> on demand when a migration is initiated and thrown away at completion.
>> I don't think we need to expose a user controlled directory as we
>> do not expect users to create the keys ahead of time.
>>
>>> 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.
>>
>> IMHO we should always use a generated PSK if VIR_MIGRATE_TLS is passed
>> and no certificates are configured for use with QEMU. I don't think we
>> need any new API flag.
>
> Agreed. I plan also as follow-up to communicate via the migration cookie
> that PSK is supported and enable it also without the TLS flag if both
> sides support it.
>
>>> 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.
>>
>>> 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.
>>
>> A key is just a set of random bytes. The user is no better at creating
>> random bytes than libvirt so I see no reason to expose this parameter.
>> It is liable to promote bad practices that an app uses a single PSK
>> for every VM.
>
> Yes. I still don't understand why anyone would want to do this when thed
> efault case is secure with 0 setup.
>
> In my reply I've agreed (hesitantly, because I think that part of the
> feature will be mostly dead code), because in the original design what
> they've proposed they had completely user/admin setup keys and the
> reasoning for it didn't make much sense.
>
> I proposed the way to pass the key via a secret as a stop-gap while the
> default being the sane 0 setup scenario, but I still don't understand
> why anyone would want to use it, and much less why bother implementing
> it.
Dear Peter and Daniel,
With regards to the discussion in the thread, I have incorporated the following
changes:
1. Libvirt manages the lifecycle of pre-shared keys.
2. Transfer of keys to the destination via the migration cookie.
3. Remove the VIR_MIGRATE_TLS_PSK flag instead rely on
VIR_MIGRATE_TLS and availability of ca-cert.pem on source.
4. Drop VIR_MIGRATE_PARAM_TLS_PSK_DIRECTORY, Libvirt solely
manages the pre-shared keys.
Thank you for the feedback. I will send out a series that just covers libvirt
generating PSKs for now. There may be clients wishing to self-generate
the keys, but we can tackle that via a future extension, if needed.
Thanks and warm regards,
Abhisek Panda
