On Tue, 27 Oct 2026 at 14:33, Fabiano Rosas <[email protected]> wrote:
>
> Peter Maydell <[email protected]> writes:
>
> > On Tue, 21 Jul 2026 at 14:15, Fabiano Rosas <[email protected]> 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
