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.