From: Dmitry Fleytman <dmitry@daynix.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Yan Vugenfirer <yan@daynix.com>,
Chris Webb <chris.webb@elastichosts.com>,
qemu-devel@nongnu.org,
Richard Davies <richard.davies@elastichosts.com>
Subject: Re: [Qemu-devel] [PATCH 1/2] Ignore RX tail kicks when RX disabled.
Date: Thu, 18 Oct 2012 10:08:02 +0200 [thread overview]
Message-ID: <CAGHCxhf=o=xucgTOQsC-7c+1--rnSv0f8fn666dJf3pryZDaXw@mail.gmail.com> (raw)
In-Reply-To: <20121018073156.GE22425@stefanha-thinkpad.redhat.com>
Hello, Stefan
The problem occurs between steps 2 and 3.
Let's say packet arrives after step 2 is done by driver.
Head and tail are 0 because of step 1
Check_rxov is 0 because of two reasons:
1. On startup it is 0 by default
2. It is zeroed by setting ring tail to 0 on first step
Then first check ( __if (!(s->mac_reg[RCTL] & E1000_RCTL_EN))__ )
passes because RX enabled on step 2.
e1000_has_rxbufs() returs true because it treats equal head and tail
as fully filled ring when check_rxov is 0:
static bool e1000_has_rxbufs(E1000State *s, size_t total_size)
{
[...]
if (total_size <= s->rxbuf_size) {
return s->mac_reg[RDH] != s->mac_reg[RDT] || !s->check_rxov;
[...]
} else if (s->mac_reg[RDH] > s->mac_reg[RDT] || !s->check_rxov) {
[...]
}
So QEMU reads uninitialized descriptor and tries to perform "DMA" to
arbitrary address from descriptor.
Depending on address value it corrupts guest memory or abort()'s here:
void *qemu_get_ram_ptr(ram_addr_t addr)
{
[...]
fprintf(stderr, "Bad ram offset %" PRIx64 "\n", (uint64_t)addr);
abort();
[...]
}
Thanks for review,
Dmitry.
On Thu, Oct 18, 2012 at 9:31 AM, Stefan Hajnoczi <stefanha@gmail.com> wrote:
>
> On Wed, Oct 17, 2012 at 08:31:46PM +0200, Dmitry Fleytman wrote:
> > Device RX initization from driver's side consists of following steps:
> > 1. Initialize head and tail of RX ring to 0
> > 2. Enable Rx (set bit in RCTL register)
> > 3. Allocate buffers, fill descriptors
> > 4. Write ring tail
> >
> > Forth operation signals hardware that RX buffers available
> > and it may start packets indication.
> >
> > Current implementation treats first operation (write 0 to ring tail)
> > as signal of buffers availability and starts data transfers as soon
> > as RX enable indicaton arrives.
> >
> > This is not correct because there is a chance that ring is still
> > empty (third action not performed yet) and then memory corruption
> > occures.
>
> The existing code tries to prevent this:
>
> e1000_receive(NetClientState *nc, const uint8_t *buf, size_t size)
> {
> [...]
>
> if (!(s->mac_reg[RCTL] & E1000_RCTL_EN))
> return -1;
>
> [...]
> total_size = size + fcs_len(s);
> if (!e1000_has_rxbufs(s, total_size)) {
> set_ics(s, 0, E1000_ICS_RXO);
> return -1;
> }
>
> Why are these checks not enough?
>
> Which memory gets corrupted?
>
> Stefan
--
Dmitry Fleytman
Technology Expert and Consultant,
Daynix Computing Ltd.
Cell: +972-54-2819481
Skype: dmitry.fleytman
next prev parent reply other threads:[~2012-10-18 8:08 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-17 18:31 [Qemu-devel] [PATCH 0/2] E1000 RX/Live migration bugs fixed Dmitry Fleytman
2012-10-17 18:31 ` [Qemu-devel] [PATCH 1/2] Ignore RX tail kicks when RX disabled Dmitry Fleytman
2012-10-18 7:31 ` Stefan Hajnoczi
2012-10-18 8:08 ` Dmitry Fleytman [this message]
2012-10-18 8:09 ` Stefan Hajnoczi
2012-10-18 8:34 ` Dmitry Fleytman
2012-10-18 14:31 ` Stefan Hajnoczi
2012-10-18 16:06 ` Alexander Duyck
2012-10-18 16:12 ` Dmitry Fleytman
2012-10-17 18:31 ` [Qemu-devel] [PATCH 2/2] Add check_rxov into VMState Dmitry Fleytman
2012-10-18 7:24 ` Stefan Hajnoczi
2012-10-18 8:06 ` Dmitry Fleytman
2012-10-18 14:56 ` 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='CAGHCxhf=o=xucgTOQsC-7c+1--rnSv0f8fn666dJf3pryZDaXw@mail.gmail.com' \
--to=dmitry@daynix.com \
--cc=chris.webb@elastichosts.com \
--cc=qemu-devel@nongnu.org \
--cc=richard.davies@elastichosts.com \
--cc=stefanha@gmail.com \
--cc=yan@daynix.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).