[PATCH v2] docs: Add security considerations for migration

[PATCH v2] docs: Add security considerations for migration

[Fabiano Rosas]

Add the security considerations that are unique to migration and that
do not already fall into one of the other categories. Some aspects are
better framed as security architecture considerations, so extend that
section to mention TLS and clarify that disk images and guest network
also need to be isolated from other processes, not just other guests.

Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
---
 docs/system/security.rst | 22 ++++++++++++++++++----
 1 file changed, 18 insertions(+), 4 deletions(-)

diff --git a/docs/system/security.rst b/docs/system/security.rst
index 52bbf0cc7a2..af626a42307 100644
--- a/docs/system/security.rst
+++ b/docs/system/security.rst
@@ -133,6 +133,16 @@ an issue as a normal bug.
   that affect the level 0 QEMU process. While these bugs should be
   fixed, they will not be triaged as security flaws at this time.
 
+* **migration/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. The
+  migration stream is assumed to be secure as long as the design
+  principles described in the Architecture section are held, in
+  which case plain manipulation of the stream is not considered as
+  an attack vector.
+
 * **low severity impact**. As a catch all rule, issues which
   are judged to have a "low" severity impact on the system will
   usually not justify handling as security bugs, nor assignment
@@ -159,10 +169,11 @@ could allow malicious guests to gain code execution in QEMU.  At this point the
 guest has escaped the virtual machine and is able to act in the context of the
 QEMU process on the host.
 
-Guests often interact with other guests and share resources with them.  A
-malicious guest must not gain control of other guests or access their data.
-Disk image files and network traffic must be protected from other guests unless
-explicitly shared between them by the user.
+Guests often interact with other guests and share resources with them.
+A malicious guest must not gain control of other guests or access
+their data.  Disk image files and network traffic must be protected
+from other guests, users and processes unless explicitly shared with
+them by the user.
 
 Principle of Least Privilege
 ''''''''''''''''''''''''''''
@@ -223,6 +234,9 @@ Some Linux distros already ship with UNIX groups for these devices by default.
   system calls that are not needed by QEMU, thereby reducing the host kernel
   attack surface.
 
+- Transport Layer Security (TLS) protocol can be used to ensure authenticity and
+  encryption of the live migration connection where the network is untrusted.
+
 Sensitive configurations
 ------------------------
 
-- 
2.53.0

Re: [PATCH v2] docs: Add security considerations for migration

[Peter Xu]

On Tue, Jul 21, 2026 at 10:14:57AM -0300, Fabiano Rosas wrote:
> Add the security considerations that are unique to migration and that
> do not already fall into one of the other categories. Some aspects are
> better framed as security architecture considerations, so extend that
> section to mention TLS and clarify that disk images and guest network
> also need to be isolated from other processes, not just other guests.
> 
> Reviewed-by: Peter Xu <peterx@redhat.com>
> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
> Signed-off-by: Fabiano Rosas <farosas@suse.de>
> ---
>  docs/system/security.rst | 22 ++++++++++++++++++----
>  1 file changed, 18 insertions(+), 4 deletions(-)

queued for 11.2, thanks.

-- 
Peter Xu

Re: [PATCH v2] docs: Add security considerations for migration

[Peter Maydell]

On Tue, 21 Jul 2026 at 14:15, Fabiano Rosas <farosas@suse.de> wrote:
>
> Add the security considerations that are unique to migration and that
> do not already fall into one of the other categories. Some aspects are
> better framed as security architecture considerations, so extend that
> section to mention TLS and clarify that disk images and guest network
> also need to be isolated from other processes, not just other guests.
>
> Reviewed-by: Peter Xu <peterx@redhat.com>
> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
> Signed-off-by: Fabiano Rosas <farosas@suse.de>
> ---
>  docs/system/security.rst | 22 ++++++++++++++++++----
>  1 file changed, 18 insertions(+), 4 deletions(-)
>
> diff --git a/docs/system/security.rst b/docs/system/security.rst
> index 52bbf0cc7a2..af626a42307 100644
> --- a/docs/system/security.rst
> +++ b/docs/system/security.rst
> @@ -133,6 +133,16 @@ an issue as a normal bug.
>    that affect the level 0 QEMU process. While these bugs should be
>    fixed, they will not be triaged as security flaws at this time.
>
> +* **migration/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. The
> +  migration stream is assumed to be secure as long as the design
> +  principles described in the Architecture section are held, in
> +  which case plain manipulation of the stream is not considered as
> +  an attack vector.

Reading this (which is now in our docs), it seems unclear to me
about whether it intends to say that any and all bugs that can
be triggered only by manipulating the migration stream are outside
the security scope, or only some of them.

It says "plain manipulation of the stream is not considered as
an attack vector", which suggests "everything is out of scope".
But on the other hand it has an explicit list ("migration
failures", "snapshot load failures", "aborting the QEMU process"),
so does it mean by that that other things than those listed
(e.g. "overruns a buffer in the destination") still are security
issues ?

I'd appreciate clarification, as it would make it easier to
triage reported issues out of the confidential state.

thanks
-- PMM

Re: [PATCH v2] docs: Add security considerations for migration

[Fabiano Rosas]

Peter Maydell <peter.maydell@linaro.org> writes:

> On Tue, 21 Jul 2026 at 14:15, Fabiano Rosas <farosas@suse.de> wrote:
>>
>> Add the security considerations that are unique to migration and that
>> do not already fall into one of the other categories. Some aspects are
>> better framed as security architecture considerations, so extend that
>> section to mention TLS and clarify that disk images and guest network
>> also need to be isolated from other processes, not just other guests.
>>
>> Reviewed-by: Peter Xu <peterx@redhat.com>
>> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
>> Signed-off-by: Fabiano Rosas <farosas@suse.de>
>> ---
>>  docs/system/security.rst | 22 ++++++++++++++++++----
>>  1 file changed, 18 insertions(+), 4 deletions(-)
>>
>> diff --git a/docs/system/security.rst b/docs/system/security.rst
>> index 52bbf0cc7a2..af626a42307 100644
>> --- a/docs/system/security.rst
>> +++ b/docs/system/security.rst
>> @@ -133,6 +133,16 @@ an issue as a normal bug.
>>    that affect the level 0 QEMU process. While these bugs should be
>>    fixed, they will not be triaged as security flaws at this time.
>>
>> +* **migration/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. The
>> +  migration stream is assumed to be secure as long as the design
>> +  principles described in the Architecture section are held, in
>> +  which case plain manipulation of the stream is not considered as
>> +  an attack vector.
>
> Reading this (which is now in our docs), it seems unclear to me
> about whether it intends to say that any and all bugs that can
> be triggered only by manipulating the migration stream are outside
> the security scope, or only some of them.
>

All of them, but we're talking specifically about feeding bad data into
QEMU from the host level.

> It says "plain manipulation of the stream is not considered as
> an attack vector", which suggests "everything is out of scope".

By "plain manipulation", we mean that if someone loads a compromised
loadvm image or if they have access to the infrastructure and proceed to
inject bytes into the migration stream that is considered out of the
scope of what we considered a security issue. The premise is that
migration is a special process that requires a secure network and the
usage of encryption. If you migrate in plain text over the internet,
that's on you.

The other scenario, this one in scope, would be an attack that starts on
the guest operating system and trips the migration code to cause an
effect. This would be an indirect stream manipulation, if we want to
call it that.

> But on the other hand it has an explicit list ("migration
> failures", "snapshot load failures", "aborting the QEMU process"),
> so does it mean by that that other things than those listed
> (e.g. "overruns a buffer in the destination") still are security
> issues ?
>

Yes, we're only isolating the scenario of attacker-controlled migration
stream at the network level. That situation is (IMO) undefendable.

All issues that lead _only_ to a migration failure while still in
precopy (including destination abort) will not cause any damage from the
perspective of the guest's isolation. Those are considered normal
operation, migrations sometimes fail.

If a legitimate migration operation - started by the admin, within a
secure network, using encryption - can be influenced to cause what would
otherwise be considered a security issue, then that's a security issue.

> I'd appreciate clarification, as it would make it easier to
> triage reported issues out of the confidential state.
>
> thanks
> -- PMM

Re: [PATCH v2] docs: Add security considerations for migration

[Peter Maydell]

On Tue, 27 Oct 2026 at 14:33, Fabiano Rosas <farosas@suse.de> wrote:
>
> Peter Maydell <peter.maydell@linaro.org> writes:
>
> > On Tue, 21 Jul 2026 at 14:15, Fabiano Rosas <farosas@suse.de> wrote:
> >> +* **migration/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. The
> >> +  migration stream is assumed to be secure as long as the design
> >> +  principles described in the Architecture section are held, in
> >> +  which case plain manipulation of the stream is not considered as
> >> +  an attack vector.
> >
> > Reading this (which is now in our docs), it seems unclear to me
> > about whether it intends to say that any and all bugs that can
> > be triggered only by manipulating the migration stream are outside
> > the security scope, or only some of them.
> >
>
> All of them, but we're talking specifically about feeding bad data into
> QEMU from the host level.
>
> > It says "plain manipulation of the stream is not considered as
> > an attack vector", which suggests "everything is out of scope".
>
> By "plain manipulation", we mean that if someone loads a compromised
> loadvm image or if they have access to the infrastructure and proceed to
> inject bytes into the migration stream that is considered out of the
> scope of what we considered a security issue. The premise is that
> migration is a special process that requires a secure network and the
> usage of encryption. If you migrate in plain text over the internet,
> that's on you.
>
> The other scenario, this one in scope, would be an attack that starts on
> the guest operating system and trips the migration code to cause an
> effect. This would be an indirect stream manipulation, if we want to
> call it that.

Thanks. I think we could maybe make the text clearer. Here's my
suggestion, that splits out the cases into a set of bullet points:

* **migration/snapshots**. The user must deploy QEMU following the
  design principles described in the Architecture section to ensure
  that the migration stream is secure. Plain manipulation of the stream
  is not considered to be an attack vector. This means that:
  * Migration failures and snapshot load failures are part of normal
    operation; these are not bugs as long as the source virtual machine
    or savevm file are still functional
  * Aborts, crashes or misbehaviour of the destination QEMU due to
    an externally manipulated migration stream are bugs, but not
    security issues
  * A crash of the destination QEMU that can be triggered by a guest
    manipulating a device on the source QEMU before a migration may
    be a security issue, if it meets the other criteria we document
    for security issues

How does that sound?

I think we should also:

 * add a subsection to the "Sensitive configurations" part of this
   document at the bottom, that makes it clear that the user needs
   to be careful about the migration stream and loadvm files
   (to parallel the one that says "it's your job to lock down
   monitor access")
 * update the part at the to of the document that includes in
   its list of untrusted entities "Network protocols (e.g. NBD,
   live migration)" as this suggests the opposite of what the
   later text says. I guess just delete "live migration" ?

We also have 15 or so existing bugs that are labelled "confidential"
but which are "crafted migration stream can exploit the destination
QEMU". Unless you object I'll mark all those as non-confidential
non-security issues.

thanks
-- PMM

Re: [PATCH v2] docs: Add security considerations for migration

[Fabiano Rosas]

Peter Maydell <peter.maydell@linaro.org> writes:

> On Tue, 27 Oct 2026 at 14:33, Fabiano Rosas <farosas@suse.de> wrote:
>>
>> Peter Maydell <peter.maydell@linaro.org> writes:
>>
>> > On Tue, 21 Jul 2026 at 14:15, Fabiano Rosas <farosas@suse.de> wrote:
>> >> +* **migration/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. The
>> >> +  migration stream is assumed to be secure as long as the design
>> >> +  principles described in the Architecture section are held, in
>> >> +  which case plain manipulation of the stream is not considered as
>> >> +  an attack vector.
>> >
>> > Reading this (which is now in our docs), it seems unclear to me
>> > about whether it intends to say that any and all bugs that can
>> > be triggered only by manipulating the migration stream are outside
>> > the security scope, or only some of them.
>> >
>>
>> All of them, but we're talking specifically about feeding bad data into
>> QEMU from the host level.
>>
>> > It says "plain manipulation of the stream is not considered as
>> > an attack vector", which suggests "everything is out of scope".
>>
>> By "plain manipulation", we mean that if someone loads a compromised
>> loadvm image or if they have access to the infrastructure and proceed to
>> inject bytes into the migration stream that is considered out of the
>> scope of what we considered a security issue. The premise is that
>> migration is a special process that requires a secure network and the
>> usage of encryption. If you migrate in plain text over the internet,
>> that's on you.
>>
>> The other scenario, this one in scope, would be an attack that starts on
>> the guest operating system and trips the migration code to cause an
>> effect. This would be an indirect stream manipulation, if we want to
>> call it that.
>
> Thanks. I think we could maybe make the text clearer. Here's my
> suggestion, that splits out the cases into a set of bullet points:
>
> * **migration/snapshots**. The user must deploy QEMU following the
>   design principles described in the Architecture section to ensure
>   that the migration stream is secure. Plain manipulation of the stream
>   is not considered to be an attack vector. This means that:
>   * Migration failures and snapshot load failures are part of normal
>     operation; these are not bugs as long as the source virtual machine
>     or savevm file are still functional
>   * Aborts, crashes or misbehaviour of the destination QEMU due to
>     an externally manipulated migration stream are bugs, but not
>     security issues
>   * A crash of the destination QEMU that can be triggered by a guest
>     manipulating a device on the source QEMU before a migration may
>     be a security issue, if it meets the other criteria we document
>     for security issues
>
> How does that sound?
>

Looks good, thanks. I'll send a patch.

> I think we should also:
>
>  * add a subsection to the "Sensitive configurations" part of this
>    document at the bottom, that makes it clear that the user needs
>    to be careful about the migration stream and loadvm files
>    (to parallel the one that says "it's your job to lock down
>    monitor access")
>  * update the part at the to of the document that includes in
>    its list of untrusted entities "Network protocols (e.g. NBD,
>    live migration)" as this suggests the opposite of what the
>    later text says. I guess just delete "live migration" ?
>

Yes, this one has been coming up frequently. The point was to keep
developers thinking about migration stream validation. But it's
misleading, better to remove it.

> We also have 15 or so existing bugs that are labelled "confidential"
> but which are "crafted migration stream can exploit the destination
> QEMU". Unless you object I'll mark all those as non-confidential
> non-security issues.
>

Ack

> thanks
> -- PMM

Re: [PATCH v2] docs: Add security considerations for migration

[Peter Maydell]

On Wed, 28 Oct 2026 at 13:51, Fabiano Rosas <farosas@suse.de> wrote:
>
> Peter Maydell <peter.maydell@linaro.org> writes:
> > Thanks. I think we could maybe make the text clearer. Here's my
> > suggestion, that splits out the cases into a set of bullet points:
> >
> > * **migration/snapshots**. The user must deploy QEMU following the
> >   design principles described in the Architecture section to ensure
> >   that the migration stream is secure. Plain manipulation of the stream
> >   is not considered to be an attack vector. This means that:
> >   * Migration failures and snapshot load failures are part of normal
> >     operation; these are not bugs as long as the source virtual machine
> >     or savevm file are still functional
> >   * Aborts, crashes or misbehaviour of the destination QEMU due to
> >     an externally manipulated migration stream are bugs, but not
> >     security issues
> >   * A crash of the destination QEMU that can be triggered by a guest
> >     manipulating a device on the source QEMU before a migration may
> >     be a security issue, if it meets the other criteria we document
> >     for security issues
> >
> > How does that sound?
> >
>
> Looks good, thanks. I'll send a patch.

Thanks. You should check whether I have the nested-bulleted list rst
syntax correct there, I just hand-wrote it in the email client :-)

> > I think we should also:
> >
> >  * add a subsection to the "Sensitive configurations" part of this
> >    document at the bottom, that makes it clear that the user needs
> >    to be careful about the migration stream and loadvm files
> >    (to parallel the one that says "it's your job to lock down
> >    monitor access")
> >  * update the part at the to of the document that includes in
> >    its list of untrusted entities "Network protocols (e.g. NBD,
> >    live migration)" as this suggests the opposite of what the
> >    later text says. I guess just delete "live migration" ?
> >
>
> Yes, this one has been coming up frequently. The point was to keep
> developers thinking about migration stream validation. But it's
> misleading, better to remove it.
>
> > We also have 15 or so existing bugs that are labelled "confidential"
> > but which are "crafted migration stream can exploit the destination
> > QEMU". Unless you object I'll mark all those as non-confidential
> > non-security issues.
> >
>
> Ack

OK, I'll do that at some point this week.

-- PMM