Re: [Qemu-devel] live snapshot wiki updated

[Eric Blake]

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.

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.

--
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org