| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] FW: Xen 3.3.0 - QEMU COW disk image with sparse backing
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
|
|
|
| |
|
Home