[libvirt] [Qemu-devel] live snapshot wiki updated

[Blue Swirl]

On Wed, Jul 20, 2011 at 8:41 PM, Eric Blake <eblake at redhat.com> wrote:
> On 07/20/2011 11:20 AM, Blue Swirl wrote:
>>
>> There could still be some issues:
>> Let's have files A, B, C etc. with backing files AA etc. How would
>> libvirt know that when QEMU wants to write to file CA, this is because
>> it's needed to access C, or is it just trickery by a devious guest to
>> corrupt storage?
>
> The fix for CVE-2010-2238 already deals with this: if primary image C refers
> to backing file CA of raw format, but does not state what file format CA
> contains, then a malicious guest can modify the contents of CA to appear to
> be yet another qcow2 image.  At which point, if libvirt follows the backing
> file specified in CA, then yes, the malicious guest really can cause libvirt
> to expose arbitrary file CB for manipulation by the guest.  But that
> security hole was already plugged - by default, libvirt refuses to probe
> backing files parsed from qcow2 headers for file format, but instead
> requires the outer qcow2 header to also include the a file format
> designation for the backing file.  At which point, you then have a safe
> chain: if C refers to CA, then libvirt knows that both C and CA are
> essential to the storage presented by giving qemu the file name C, and the
> guest will already be modifying CA, but there is no storage corruption
> involved.

But what if CA is accessed even if C is not? For example, QEMU opens C
(to determine CA and write new information about the path), closes it
and then requests CA?

> That is, as long as libvirt can already accurately read the chain of backing
> files from any starting point, then it can hand that entire chain of backing
> files (whether by the topmost file name as it does now, or whether by a
> series of fds as is being proposed) to qemu.
>
>>
>> This could be handled so that instead of naming the backing file, QEMU
>> asks for a descriptor for the backing file by presenting the
>> descriptor to main file C, but I think the real solution is that
>> libvirt should handle the storage formats completely and it should
>> present QEMU with only a raw file like interface (read/write/seek) for
>> the data. Then any backing files would be handled within libvirt.
>> Performance could suffer, though.
>
> The monitor interface was not designed to throw the read()/write()/seek()
> burden back on libvirt, and indeed that would kill performance so it is a
> non-starter idea.  All we need for security is the open() burden to be
> shifted out of qemu and into libvirt.

Obviously the interface should be faster than monitor, for example a
pair of sockets with some efficient protocol. Monitor could still be
used to set up these.