[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] FW: Xen 3.3.0 - QEMU COW disk image with sparse backing file - VM fails to start
Martin Tröster writes ("[Xen-devel] FW: Xen 3.3.0 - QEMU COW disk > image with sparse backing file - VM fails to start"): Therefore, let > me kindly ask why it is considered to "handle QCOW backing files > correctly" now? The patch, in my eyes, allows to use a raw file as > backing file, but breaks the use of a QCOW file (sparse file, in my > setup) as a backing file. In my setup, this breaks the use of all > current QCOW-files I am running when migrating from Xen-3.2 to > Xen-3.3. I'm sorry to have to tell you that this isn't easy to fix in general, although I can point you where to make a specific patch which may work for you. The feature you were using (qcow backing files) has been disabled as a security measure. It is also possible that your existing installation is vulnerable to a the qcow format-guessing vulnerability. The root cause of the problem is as follows: > > The image structure is: > > Base File A.img (sparse QCOW2 file) > > COW File B.img (QCOW2 file with A.img as backing file) > > used as disk in Xen config file (see VM config file below) File B.img contains the filename of A.img - but it does not contain any information about the format. Prior to fixing the security problem, qemu (qemu-dm aka ioemu) would read the start of A.img to try to determine what kind of file it was. Since A.img has a qcow2 header it would treat it as a qcow2 file. In your case that's it, but in the general case A.img will itself have the filename of a backing file, let us say Z.img. Unfixed qemu would again guess the format of Z.img by reading the header. Eventually some raw disk image would be found. The problem is that if any untrusted guest can ever write the raw disk image they can write a qcow header on the front of it. That qcow header can contain a filename which the next invocation of qemu will open and allow the guest to read (parts of, at least). So I `fixed' this by making all backing files of cow images always be treated as raw images. (In upstream this is being fixed by adding more metadata to the data format but the exact syntax is still settling down and this change comes too late for Xen 3.3.) The code which does this is this line if (bdrv_open2(bs->backing_hd, backing_filename, open_flags, &bdrv_raw) < 0) in bdrv_open2 in block.c. The critical part is here: ^^^^^^^^^ If you change that to bdrv_qcow2 you may find that it all works. But you will no longer be able to use qcow2 files with raw backing images. Good luck! Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |