This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [PATCH] ioemu block device extent checks

To: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] ioemu block device extent checks
From: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Date: Tue, 26 Feb 2008 20:41:30 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 26 Feb 2008 12:41:59 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <18363.1536.661607.292188@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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <18363.1536.661607.292188@xxxxxxxxxxxxxxxxxxxxxxxx>
Reply-to: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.1i
On Tue, Feb 19, 2008 at 04:38:24PM +0000, Ian Jackson wrote:
Content-Description: message body text
> When a block device read or write request is made by an HVM guest,
> nothing checks that the request is within the range supported by the
> block backend driver in ioemu, but the code in the backend driver
> typically assumes that the request is sensible.
> Depending on the backend, this can allow the guest to read and write
> arbitrary memory locations in qemu, and possibly gain control over the
> qemu process, escaping from the virtualisation.
> I have demonstrated to my own satisfaction that there is problem,
> using a modified Linux kernel as a guest with an instrumented CVS head
> qemu.  I haven't yet reproduced the bug with xen-unstable but I think
> it's almost certainly there too.  I have prepared a patch which I have
> checked prevents my test case, and adjusted it to fit and compile
> against xen-unstable.  I'm subjecting it to some testing as I write.

FYI, this patch causes massive unrecoverable data loss / corruption on
QCow2 files. The checks themselves are OK in terms of the first level
of bdrv_* calls from the guest. The qcow driver though calls back into
the raw driver for performing I/O on its underlying file. The qcow 
driver relies on this file being grow-on-demand for purposes of allocating
new qcow sectors. The safety checks cause this allocation to fail and
it all goes downhill from there :-(  

|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

Xen-devel mailing list