From: Vlad Yasevich <vyasevic@redhat.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: jasowang@redhat.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 2/2] rtl8139: correctly track full receive buffer in standard mode
Date: Wed, 26 Aug 2015 09:07:34 -0400 [thread overview]
Message-ID: <55DDBA16.10301@redhat.com> (raw)
In-Reply-To: <20150826123617.GF30715@stefanha-thinkpad.redhat.com>
On 08/26/2015 08:36 AM, Stefan Hajnoczi wrote:
> On Fri, Aug 21, 2015 at 02:59:25PM -0700, Vladislav Yasevich wrote:
>> In standard operation mode, when the receive ring buffer
>> is full, the buffer actually appears empty to the driver since
>> the RxBufAddr (the location we wirte new data to) and RxBufPtr
>> (the location guest would stat reading from) are the same.
>> As a result, the call to rtl8139_RxBufferEmpty ends up
>> returning true indicating that the receive buffer is empty.
>> This would result in the next packet overwriting the recevie buffer
>> again and stalling receive operations.
>>
>> This patch catches the "receive buffer full" condition
>> using an unused C+ register. This is done to simplify
>> migration and not require a new machine type.
>>
>> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
>> ---
>> hw/net/rtl8139.c | 36 ++++++++++++++++++++++++++++++++++--
>> 1 file changed, 34 insertions(+), 2 deletions(-)
>
> The rtl8139 code duplicates the following expression in several places:
>
> MOD2(s->RxBufferSize + s->RxBufAddr - s->RxBufPtr, s->RxBufferSize);
>
> It may be cleaner to keep a rx_unread_bytes counter so that all these
> users can simply look at that variable.
>
> That cleanup also eliminates the rx full vs empty problem because then
> we'll know whether rx_unread_bytes == 0 or rx_unread_bytes ==
> s->RxBufferSize.
>
> The same trick of stashing the value in s->currCPlusRxDesc could be
> used.
>
Good idea. I'll give it a try.
>> diff --git a/hw/net/rtl8139.c b/hw/net/rtl8139.c
>> index 359e001..3d572ab 100644
>> --- a/hw/net/rtl8139.c
>> +++ b/hw/net/rtl8139.c
>> @@ -816,6 +816,23 @@ static int rtl8139_can_receive(NetClientState *nc)
>> }
>> }
>>
>> +static void rtl8139_set_rxbuf_full(RTL8139State *s, bool full)
>> +{
>> + /* In standard mode, C+ RxDesc isn't used. Reuse it
>> + * to store the rx_buf_full status.
>> + */
>
> assert(!s->cplus_enabled)?
>
>> + s->currCPlusRxDesc = full;
>> + DPRINTF("received: rx buffer full\n");
>> +}
>> +
>> +static bool rtl8139_rxbuf_full(RTL8139State *s)
>> +{
>> + /* In standard mode, C+ RxDesc isn't used. Reuse it
>> + * to store the rx_buf_full status.
>> + */
>
> assert(!s->cplus_enabled)?
>
>> @@ -2601,6 +2630,9 @@ static void rtl8139_RxBufPtr_write(RTL8139State *s, uint32_t val)
>> /* this value is off by 16 */
>> s->RxBufPtr = MOD2(val + 0x10, s->RxBufferSize);
>>
>> + /* We just read data, clear full buffer state */
>> + rtl8139_set_rxbuf_full(s, false);
>> +
>> /* more buffer space may be available so try to receive */
>> qemu_flush_queued_packets(qemu_get_queue(s->nic));
>
> What if the guest writes this register while we're in C+ mode?
>
In C+ mode the guest uses a descriptor ring instead of liner buffer so a well behaved
C+ guest wouldn't write this value. Validated this with a linux guest.
I guess a malicious guest could do this, but then it could do a lot of other things too.
-vlad
next prev parent reply other threads:[~2015-08-26 13:07 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-21 21:59 [Qemu-devel] [PATCH 0/2] rtl8139: Fix buffer overflow in standard mode Vladislav Yasevich
2015-08-21 21:59 ` [Qemu-devel] [PATCH 1/2] rtl8139: Do not consume the packet during " Vladislav Yasevich
2015-08-26 12:18 ` Stefan Hajnoczi
2015-08-26 13:02 ` Vlad Yasevich
2015-08-21 21:59 ` [Qemu-devel] [PATCH 2/2] rtl8139: correctly track full receive buffer " Vladislav Yasevich
2015-08-26 12:36 ` Stefan Hajnoczi
2015-08-26 13:07 ` Vlad Yasevich [this message]
-- strict thread matches above, loose matches on Subject: below --
2015-08-26 19:51 [Qemu-devel] [PATCH v2 0/2] rtl8139: Fix buffer overflow " Vladislav Yasevich
2015-08-26 19:51 ` [Qemu-devel] [PATCH 2/2] rtl8139: correctly track full receive buffer " Vladislav Yasevich
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=55DDBA16.10301@redhat.com \
--to=vyasevic@redhat.com \
--cc=jasowang@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.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.