All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [PATCH] ioemu block device extent checks
Date: Tue, 26 Feb 2008 20:41:30 +0000	[thread overview]
Message-ID: <20080226204130.GC24548@redhat.com> (raw)
In-Reply-To: <18363.1536.661607.292188@mariner.uk.xensource.com>

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  -=| 

  reply	other threads:[~2008-02-26 20:41 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-19 16:38 [PATCH] ioemu block device extent checks Ian Jackson
2008-02-26 20:41 ` Daniel P. Berrange [this message]
2008-02-27 11:28   ` Ian Jackson
2008-02-27 12:57     ` Daniel P. Berrange
2008-02-27 13:14       ` Ian Jackson
2008-02-27 13:21         ` Daniel P. Berrange
2008-03-04 10:16   ` Kevin Wolf
2008-03-04 10:08     ` Keir Fraser
2008-03-04 11:05       ` Kevin Wolf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080226204130.GC24548@redhat.com \
    --to=berrange@redhat.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.