Peter Maydell <[email protected]> writes:
> On Tue, 21 Jul 2026 at 14:15, Fabiano Rosas <[email protected]> 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 <[email protected]>
>> Reviewed-by: Daniel P. Berrangé <[email protected]>
>> Signed-off-by: Fabiano Rosas <[email protected]>
>> ---
>> 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
