All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gleb Natapov <gleb@redhat.com>
To: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
Cc: Avi Kivity <avi@redhat.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>, KVM <kvm@vger.kernel.org>
Subject: Re: [PATCH] KVM: x86: fix vcpu->mmio_fragments overflow
Date: Mon, 22 Oct 2012 13:23:14 +0200	[thread overview]
Message-ID: <20121022112314.GO29310@redhat.com> (raw)
In-Reply-To: <50852972.305@linux.vnet.ibm.com>

On Mon, Oct 22, 2012 at 07:09:38PM +0800, Xiao Guangrong wrote:
> On 10/22/2012 05:16 PM, Gleb Natapov wrote:
> > On Fri, Oct 19, 2012 at 03:37:32PM +0800, Xiao Guangrong wrote:
> >> After commit b3356bf0dbb349 (KVM: emulator: optimize "rep ins" handling),
> >> the pieces of io data can be collected and write them to the guest memory
> >> or MMIO together.
> >>
> >> Unfortunately, kvm splits the mmio access into 8 bytes and store them to
> >> vcpu->mmio_fragments. If the guest uses "rep ins" to move large data, it
> >> will cause vcpu->mmio_fragments overflow
> >>
> >> The bug can be exposed by isapc (-M isapc):
> >>
> >> [23154.818733] general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC
> >> [ ......]
> >> [23154.858083] Call Trace:
> >> [23154.859874]  [<ffffffffa04f0e17>] kvm_get_cr8+0x1d/0x28 [kvm]
> >> [23154.861677]  [<ffffffffa04fa6d4>] kvm_arch_vcpu_ioctl_run+0xcda/0xe45 [kvm]
> >> [23154.863604]  [<ffffffffa04f5a1a>] ? kvm_arch_vcpu_load+0x17b/0x180 [kvm]
> >>
> >>
> >> Actually, we can use one mmio_fragment to store a large mmio access for the
> >> mmio access is always continuous then split it when we pass the mmio-exit-info
> >> to userspace. After that, we only need two entries to store mmio info for
> >> the cross-mmio pages access
> >>
> > I wonder can we put the data into coalesced mmio buffer instead of
> 
> If we put all mmio data into coalesced buffer, we should:
> - ensure the userspace program uses KVM_REGISTER_COALESCED_MMIO to register
>   all mmio regions.
> 
It appears to not be so.
Userspace calls kvm_flush_coalesced_mmio_buffer() after returning from
KVM_RUN which looks like this:

void kvm_flush_coalesced_mmio_buffer(void)
{
    KVMState *s = kvm_state;

    if (s->coalesced_flush_in_progress) {
        return;
    }

    s->coalesced_flush_in_progress = true;

    if (s->coalesced_mmio_ring) {
        struct kvm_coalesced_mmio_ring *ring = s->coalesced_mmio_ring;
        while (ring->first != ring->last) {
            struct kvm_coalesced_mmio *ent;

            ent = &ring->coalesced_mmio[ring->first];

            cpu_physical_memory_write(ent->phys_addr, ent->data, ent->len);
            smp_wmb();
            ring->first = (ring->first + 1) % KVM_COALESCED_MMIO_MAX;
        }
    }

    s->coalesced_flush_in_progress = false;
}

Nowhere in this function we check that MMIO region was registered with
KVM_REGISTER_COALESCED_MMIO. We do not even check that the address is
MMIO.

> - even if the MMIO region is not used by emulated-device, it also need to be
>   registered.
Same. I think writes to non registered region will be discarded.

> 
> It will breaks old version userspace program.
> 
> > exiting for each 8 bytes? Is it worth the complexity?
> 
> Simpler way is always better but i failed, so i appreciate your guys comments.
> 
Why have you failed? Exiting for each 8 bytes is infinitely better than
buffer overflow.  My question about complexity was towards theoretically
more complex code that will use coalesced MMIO buffer.

--
			Gleb.

  reply	other threads:[~2012-10-22 11:23 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-19  7:37 [PATCH] KVM: x86: fix vcpu->mmio_fragments overflow Xiao Guangrong
2012-10-19  7:39 ` [PATCH] emulator test: add "rep ins" mmio access test Xiao Guangrong
2012-11-01  0:05   ` Marcelo Tosatti
2012-10-22  9:16 ` [PATCH] KVM: x86: fix vcpu->mmio_fragments overflow Gleb Natapov
2012-10-22 11:09   ` Xiao Guangrong
2012-10-22 11:23     ` Gleb Natapov [this message]
2012-10-22 11:35       ` Jan Kiszka
2012-10-22 11:43         ` Gleb Natapov
2012-10-22 11:45           ` Jan Kiszka
2012-10-22 12:18             ` Avi Kivity
2012-10-22 12:45               ` Jan Kiszka
2012-10-22 12:53                 ` Gleb Natapov
2012-10-22 12:55                   ` Jan Kiszka
2012-10-22 12:58                     ` Avi Kivity
2012-10-22 13:05                       ` Jan Kiszka
2012-10-22 13:08                         ` Gleb Natapov
2012-10-22 13:25                           ` Jan Kiszka
2012-10-22 14:00                             ` Gleb Natapov
2012-10-22 14:23                               ` Jan Kiszka
2012-10-22 15:36                               ` Avi Kivity
2012-10-22 12:58                     ` Gleb Natapov
2012-10-22 12:55                   ` Avi Kivity
2012-10-22 13:01                     ` Gleb Natapov
2012-10-22 13:02                       ` Avi Kivity
2012-10-22 13:05                         ` Gleb Natapov
2012-10-22 12:56                 ` Avi Kivity
2012-10-22 13:58 ` Avi Kivity

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=20121022112314.GO29310@redhat.com \
    --to=gleb@redhat.com \
    --cc=avi@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=xiaoguangrong@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.