|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel][PATCH]ioemu:fix up error when using qemu-img-xen to crea
To: |
Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> |
Subject: |
Re: [Xen-devel][PATCH]ioemu:fix up error when using qemu-img-xen to create img |
From: |
"Daniel P. Berrange" <berrange@xxxxxxxxxx> |
Date: |
Tue, 5 May 2009 15:28:23 +0100 |
Cc: |
"Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Li, Xin" <xin.li@xxxxxxxxx>, "Zhang, Yang" <yang.zhang@xxxxxxxxx> |
Delivery-date: |
Tue, 05 May 2009 07:29:33 -0700 |
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
In-reply-to: |
<18944.19070.403451.993996@xxxxxxxxxxxxxxxxxxxxxxxx> |
List-help: |
<mailto:xen-devel-request@lists.xensource.com?subject=help> |
List-id: |
Xen developer discussion <xen-devel.lists.xensource.com> |
List-post: |
<mailto:xen-devel@lists.xensource.com> |
List-subscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |
List-unsubscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |
References: |
<10C63FAD690C13458F0B32BCED571F1412A2344B@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <E88DD564E9DC5446A76B2B47C3BCCA155C2840AE@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <E88DD564E9DC5446A76B2B47C3BCCA155C30EA6D@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <18936.29628.474866.270018@xxxxxxxxxxxxxxxxxxxxxxxx> <18938.49959.734396.339825@xxxxxxxxxxxxxxxxxxxxxxxx> <EADF0A36011179459010BDF5142A4575154E1104@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <EADF0A36011179459010BDF5142A4575154E133F@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <18944.19070.403451.993996@xxxxxxxxxxxxxxxxxxxxxxxx> |
Reply-to: |
"Daniel P. Berrange" <berrange@xxxxxxxxxx> |
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
User-agent: |
Mutt/1.4.1i |
On Tue, May 05, 2009 at 03:17:34PM +0100, Ian Jackson wrote:
>
> Consider a raw disk image file which is writeable by a guest. (This
> is of course one very common usage model.) The guest can write
> anything it likes to the image file, including anything to the start
> of the file - where the cow header would be if it were a cow file.
>
> So it can, if it likes, write a cow header (qcow2 for example) to the
> start of its `virtual disk image'. Qemu's cow headers contain the
> pathname of the backing file, and the guest can of course name any
> file it likes.
>
> If this image, which is supposedly a raw image, is then opened by any
> tool which autoguesses the format, that tool will then spot the cow
> header written by the guest and access the backing file (in the
> context of the host) specified by the guest.
>
> Depending on the exact circumstances this can allow the guest to get
> copies of or even complete read access to any data of its choice in
> the host.
>
> Upstream qemu have fixed this problem in a half-hearted way and
> evidently their qemu-img is still vulnerable. We have changed the
> format-determination code in block.c so that any attempt to autodetect
> a format never returns `raw'; that means that any vulnerable code
> anywhere is instantly fixed although it may break some existing usages
> in cases where we haven't properly plumbed through a specification of
> the image format.
Wasn't the upstream change to add a '-F baseimage_format' enough to
allow the flaw to be avoided when creating new images ? Or are you
attempting to prevent the issue, even when -F is not used ?
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|