Re: [Qemu-devel] About VM fork in QEMU

[Xinyang Ge <xxg113@cse.psu.edu>]

> Live cloning is a disaster waiting to happen if not done in a very
> carefully controlled environment (I could maybe see it useful across two
> private networks for forensic analysis or running "what-if" scenarios,
> but never for provisioning enterprise-quality public-facing servers).
> Remember, if you ever expose both forks of a live clone to the same
> network at the same time, you have a security vulnerability if you did
> not manage to scrube the random pool of the two guests to be different,
> where the crypto behavior of the second guest can be guessed by
> observing the behavior of the first. But scrubbing memory correctly
> requires knowing EXACTLY where in memory the random pool is stored,
> which is highly guest-dependent, and may be spread across multiple guest
> locations.  With offline disk images, the set of information to scrub is
> a bit easier, and in fact, 'virt-sysprep' from the libguestfs tools can
> do it for a number of guests, but virt-sysprep (rightfully) refuses to
> try to scrub a live image.  Do your forked guests really have to run in
> parallel, or is it sufficient to serialize the running of one variation
> followed by the other variation?

It's better to have them run in parallel since our project doesn't
have any network stuff. However, running each variation sequentially
is also sufficient for us. What we are concerned the most is whether
we can get a snapshot in milliseconds because we don't really need to
save the memory state to disk for future reversion. Could you let me
know if it's possible for qemu or qemu-kvm with minor changes?

> As far as I know, the only way to run two guests that diverge from the
> same live state is to take a snapshot and then run two qemu instances
> that both point to that common state as their starting point, and I
> would personally never attempt it in parallel.  Meanwhile, although you
> complained that snapshots are too heavyweight, it's really the only way
> I know to even begin to attempt live cloning with current qemu.  Of
> course, being open source, you're welcome to submit a patch to add
> features to qemu to do a faster live clone.  But be prepared for an
> uphill battle if you cannot prove that such a patch does not introduce
> security implications running improperly scrubbed forks in parallel.

Thanks for letting me know about it. Yes, if only there's
communication between the guest and outside world, live cloning can
bring a bunch of security issues (e.g., IP address spoofing). But
since in our scenario VM doesn't have any network stuff, we would be
happy if only there's a quick-and-dirty way to implement it.


Xinyang

--
Xinyang GE
Department of Computer Science & Engineering
The Pennsylvania State University
Homepage: http://www.cse.psu.edu/~xxg113/