Re: [libvirt] [Qemu-devel] live snapshot wiki updated
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 eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org