Xen 3.4.1 and QCOW - sparse backing file support gone forever?

Xen 3.4.1 and QCOW - sparse backing file support gone forever?

[Martin Troester]

Hi,

I'd like to get some hints on using or migrating QCOW images with sparse
backing files.

In February, I posted a question about this and got some hints by Ian
which generally state this support was removed/disabled due to a
possible security issue. For the full thread, please see the post at
http://lists.xensource.com/archives/html/xen-devel/2009-02/msg00150.html

So with Xen 3.4.1 being released already, it seems like I am stuck now
with my chosen approach of having a qcow file which points to another
(non-raw) qcow backing file. This does not boot, everything looks as in
the February Xen 3.3 posting.

Ian, these comments from your last response particularly are of interest
to me:
> 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.)
Can you or some qemu developer reading this please explain if this code
actually made it into 3.4.1, and if yes, how I would migrate my existing
files to contain this "more metadata" to be working again?

If that's not in, is there any plan how to deal with scenarios like
mine? Especially, is there way to convert my images to some usable
format for not having to stick to Xen 3.2.1? Or is it just too exotic so
that I throw everything away and think of something else? (I am still
thinking that stacking qcow images is not the most stupid thing to do...)

Thanks for any support and hints on this topic!

Regards,
Martin

Re: Xen 3.4.1 and QCOW - sparse backing file support gone forever?

[Ian Jackson]

Martin Troester writes ("[Xen-devel] Xen 3.4.1 and QCOW - sparse backing file support gone forever?"):
> Can you or some qemu developer reading this please explain if this code
> actually made it into 3.4.1, and if yes, how I would migrate my existing
> files to contain this "more metadata" to be working again?

No, it's not in 3.4.1, and it won't be in any later 3.4.x.

qemu upstream have been racing ahead and playing catchup didn't seem
to be working well so I'm hoping that the qemu will fork a stable
branch in time to update to it for Xen 3.5, in which case this problem
will be fixed then.

> If that's not in, is there any plan how to deal with scenarios like
> mine? Especially, is there way to convert my images to some usable
> format for not having to stick to Xen 3.2.1? Or is it just too exotic so
> that I throw everything away and think of something else? (I am still
> thinking that stacking qcow images is not the most stupid thing to do...)

If it works for you then your system may have a security problem.  I
haven't analysed this use case in detail and it would depend on the
exact structure of your storage.

Alternatively a workaround for you might be to force it always to
assume qcow2 for files rather than raw, if you don't have any raw disk files.

Ian.

Re: Xen 3.4.1 and QCOW - sparse backing file support gone forever?

[Martin Troester]

Ian,

thanks for giving me some details on a possible change for Xen 3.5.

Ian Jackson wrote:
> Martin Troester writes ("[Xen-devel] Xen 3.4.1 and QCOW - sparse backing file support gone forever?"):
>> If that's not in, is there any plan how to deal with scenarios like
>> mine? Especially, is there way to convert my images to some usable
>> format for not having to stick to Xen 3.2.1? Or is it just too exotic so
>> that I throw everything away and think of something else? (I am still
>> thinking that stacking qcow images is not the most stupid thing to do...)
> 
> If it works for you then your system may have a security problem.  I
> haven't analysed this use case in detail and it would depend on the
> exact structure of your storage.
I think I am still missing the point on the severity of this attack.

Assuming I offer a user a virtual machine with a qcow2 image backed by 
another qcow2 image which is ultimately backed by a raw image, how would 
a user ever get the possibility to modify the first part of the raw 
image to resemble a qcow header? This seems to be the point where I have 
problems following your scenario. From my understanding, the user would 
always do modifications on the upper layer of the stack of files, only 
reading from below, writing to "his" proper layer. If that was not the 
case, he would be able to compromise other layer's data, even without 
the qcow header vs. raw story, right?

So, how would a user ever get the possibility to write the raw part? 
Only other option I can think of is giving the user access to the files 
themselves (e.g. via a user account in Dom0, or any other means of file 
access to that container), but that would be a security issue by itself, 
even without the whole header discussion, wouldn't it?

I hope I'm not making a fool of myself here, but I thought I'd put my 
thoughts here to understand where I'm missing the point. If this does 
not belong to this list, I'd be happy to get your answer via private mail.

Thanks for some more hints on this issue!

Kind Regards,
Martin

Re: Xen 3.4.1 and QCOW - sparse backing file support gone forever?

[Ian Jackson]

Martin Troester writes ("Re: [Xen-devel] Xen 3.4.1 and QCOW - sparse backing file support gone	forever?"):
> Ian Jackson wrote:
> > If it works for you then your system may have a security problem.  I
> > haven't analysed this use case in detail and it would depend on the
> > exact structure of your storage.
...
> Assuming I offer a user a virtual machine with a qcow2 image backed by 
> another qcow2 image which is ultimately backed by a raw image, how would 
> a user ever get the possibility to modify the first part of the raw 
> image to resemble a qcow header? This seems to be the point where I have 
> problems following your scenario. 

Ah, yes, you are right.  I think your case is safe - provided your
base images are only ever constructed by you.  But if you ever (for
example) fold changes from the upper layers back into the raw base
image and then use that as the new base, you're vulnerable again; or
if you ever accept a raw image from someone else (for testing, say).
So it's possible to avoid the problem by carefully restricting the
operations you perform, but it's hazardous because you need to be
constantly watchful.

Unfortunately to make your case work without reintroducing the
vulnerability for users with simple raw images is not trivial, because
as I say the information about what format is expected (and the
context, which might show that it was safe).

So I would suggest that the best thing for you to do would be to carry
the local change to undo the security fix, and be very careful about
how you use your images.

> I hope I'm not making a fool of myself here, but I thought I'd put my 
> thoughts here to understand where I'm missing the point. If this does 
> not belong to this list, I'd be happy to get your answer via private mail.

No, I think it's fine to have it here.  Sorry to reply late; I've been
away the last week.

Regards,
Ian.