Peter Maydell <[email protected]> writes: > 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? >
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
