From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Daniel P. Berrange" Subject: Re: [PATCH] ioemu block device extent checks Date: Tue, 26 Feb 2008 20:41:30 +0000 Message-ID: <20080226204130.GC24548@redhat.com> References: <18363.1536.661607.292188@mariner.uk.xensource.com> Reply-To: "Daniel P. Berrange" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <18363.1536.661607.292188@mariner.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Jackson Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org 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 :-( Dan. -- |=- 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 -=|