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

[Fabiano Rosas <farosas@suse.de>]

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