All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anthony PERARD <anthony.perard@citrix.com>
To: Anthony Liguori <aliguori@us.ibm.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] [PATCH] Make default invocation of block drivers safer	(v3)
Date: Tue, 27 Jul 2010 18:01:08 +0100	[thread overview]
Message-ID: <4C4F10D4.8020708@citrix.com> (raw)
In-Reply-To: <1279198257-23681-1-git-send-email-aliguori@us.ibm.com>

Anthony Liguori wrote:
> CVE-2008-2004 described a vulnerability in QEMU whereas a malicious user could
> trick the block probing code into accessing arbitrary files in a guest.  To
> mitigate this, we added an explicit format parameter to -drive which disabling
> block probing.
> 
> Fast forward to today, and the vast majority of users do not use this parameter.
> libvirt does not use this by default nor does virt-manager.
> 
> Most users want block probing so we should try to make it safer.
> 
> This patch adds some logic to the raw device which attempts to detect a write
> operation to the beginning of a raw device.  If the first 4 bytes happen to
> match an image file that has a backing file that we support, it scrubs the
> signature to all zeros.  If a user specifies an explicit format parameter, this
> behavior is disabled.
> 
> I contend that while a legitimate guest could write such a signature to the
> header, we would behave incorrectly anyway upon the next invocation of QEMU.
> This simply changes the incorrect behavior to not involve a security
> vulnerability.
> 
> I've tested this pretty extensively both in the positive and negative case.  I'm
> not 100% confident in the block layer's ability to deal with zero sized writes
> particularly with respect to the aio functions so some additional eyes would be
> appreciated.
> 
> Even in the case of a single sector write, we have to make sure to invoked the
> completion from a bottom half so just removing the zero sized write is not an
> option.
> 
> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
> ---
> v2 -> v3
>  - add an assert to ensure the first iovec element is at least 512 bytes
> v1 -> v2
>  - be more paranoid about empty iovecs
> ---
>  block.c     |    4 ++
>  block/raw.c |  130 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  block_int.h |    1 +
>  3 files changed, 135 insertions(+), 0 deletions(-)


>  static BlockDriverAIOCB *raw_aio_writev(BlockDriverState *bs,
>      int64_t sector_num, QEMUIOVector *qiov, int nb_sectors,
>      BlockDriverCompletionFunc *cb, void *opaque)
>  {
> +    const uint8_t *first_buf;
> +    int first_buf_index = 0, i;
> +
> +    /* This is probably being paranoid, but handle cases of zero size
> +       vectors. */
> +    for (i = 0; i < qiov->niov; i++) {
> +        if (qiov->iov[i].iov_len) {
> +            assert(qiov->iov[i].iov_len >= 512);
> +            first_buf_index = i;
> +            break;
> +        }
> +    }

Hi,

I have try to do an installation of Windows XP SP2, with qemu fd2f659,
and the Assertion failed when windows begin to format the disk.

The command line and the error message:
$ i386-softmmu/qemu -hda vm.img -cdrom winxpsp2.iso -boot dc
qemu: qemu/block/raw.c:130: raw_aio_writev: Assertion `qiov->iov[i].iov_len >= 512' failed.

And here, a little more information about the iov:
(gdb) p *qiov
$2 = {iov = 0x9106010, niov = 2, nalloc = 2, size = 512}
(gdb) p qiov->iov[0]
$3 = {iov_base = 0xaff3ce90, iov_len = 368}
(gdb) p qiov->iov[1]
$4 = {iov_base = 0xaff3f000, iov_len = 144}

Without the assert, the install work fine.

Regards,

-- 
Anthony PERARD

  parent reply	other threads:[~2010-07-27 17:01 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-15 12:50 [Qemu-devel] [PATCH] Make default invocation of block drivers safer (v3) Anthony Liguori
2010-07-15 13:01 ` [Qemu-devel] " Kevin Wolf
2010-07-27 17:01 ` Anthony PERARD [this message]
2010-07-27 17:16   ` [Qemu-devel] " Anthony Liguori
2010-07-27 17:43     ` Anthony PERARD
2010-07-27 18:25       ` Anthony Liguori
2010-09-03  8:42         ` 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=4C4F10D4.8020708@citrix.com \
    --to=anthony.perard@citrix.com \
    --cc=aliguori@us.ibm.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@linux.vnet.ibm.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.