On Mon, Jul 20, 2026 at 01:14:18PM -0300, Fabiano Rosas wrote: > Daniel P. Berrangé <[email protected]> writes: > > > On Thu, Jul 16, 2026 at 11:08:49AM -0300, Fabiano Rosas wrote: > >> Assumptions: > >> > >> A) The migration stream is assumed to be secured by TLS on a per-host > >> basis. > >> > >> B) For migration streams stored to file, including snapshots, it is > >> assumed that the storage file is authentic, i.e. the files are owned by > >> the party performing the live migration and have not been tampered with. > >> > >> C) The network ports used for migration are expected to be available > >> only during migration. No long-standing listening destination QEMU > >> process. > >> > >> D) The network used for migration is expected to be adequately isolated. > >> > >> E) The migration source QEMU process is assumed to be secure. Compromise > >> of the source QEMU process is nonetheless possible but exploiting the > >> migration process is expected to grant no further privileges. > > > > > > In the security.rst doc, we have an "Architecture" heading where > > we outline design principals for security. The "Assumptions" feels > > like it has overlap with that section. > > > > What if we tweak that section to be more broad? > > - Under "Guest Isolation": > > Disk image files and network traffic must be protected from other guests... > > s/unless explicitly shared between/, users and processes unless explicitly > shared with/ > > ... them by the user. > > - Under Isolation Mechanisms, we can add a bullet: > > - Transport Layer Security (TLS) protocol can be used to ensure > hypervisor authenticity and encryption of the live migration > connection. > > I can send a separate patch with this. > > >> For security consideration, the following are considered: > >> > >> OUT OF SCOPE: > >> > >> 1) Abort of destination QEMU process while migration is still in course. > >> Rationale: the source virtual machine is not affected. > >> > >> 2) Migration failure. > >> Rationale: eventual failed migrations are part of normal operation. > >> > >> 3) Memory over-allocation issues in the destination QEMU process. > >> Rationale: the destination host's operating system is expected to > >> constrain resource usage. Process termination due to OOM falls under > >> point 1 above. > > > > The "Security boundary scope" section has primarily been listing > > things that are definitely "out of scope". > > > > I think the only point not yet covered is the destination crash > situation, could we add this to your patch?
FYI, my patch is already merged, so please just submit a followup patch to augment the info I added. > > * **migration and snapshots**. Migration failures and snapshot load > failures are considered part of normal operation as long as the source > virtual machine and savevm file, respectively, are still > functional. Aborting the QEMU process at the migration/snapshot > destination is similarly not considered a security issue. We should likely distinguish live migration from snapshots a little. In live migration if loading aborts, we still have the source VM running fine. With snapshots if you launch a new QEMU and restore from snapshot there was no source VM that's relevant. With snapshots if you have a running QEMU and rollback to a snapshot (with loadvm), and QEMU crashes, you've lost your currently running QEMU. With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
