Re: [Qemu-devel] e1000 memory corruption in guest OS

[Alexey Kardashevskiy <aik@ozlabs.ru>]

On 02/16/2014 03:29 PM, Hoyer, David wrote:

> We are using Qemu-1.7.0 with Xen-4.3.0 and Debian jessie.   We are
> noticing that when we transfer large files from our network to the
> guestOS via the e1000 virtual network device that we experience memory
> corruption on the guestOS.   We have debugged this problem and have
> determined where it appears that the corruption is happening and have
> created a patch file with a fix (at least the corruption is no longer
> happening on our guestOS anymore).     Note that our test file is a
> large file consisting of the value 0x61 repeated over the entire file.
> 

> To troubleshoot this issue, we enabled tracing in qemu and used the
> xen_map_cache and xen_map_cache_return trace events.  We also added some
> of our own debug statements in e1000.c before and after the function
> call to DMA the network packet to the guestOS descriptor address.  Below
> is a commented summary of the trace output:
> 

> /*** Check if guestOS address 0xe00000 (which maps to 0x7f15c313f000) is corrupted
> xen_map_cache want 0xe00000
> xen_map_cache_return 0x7f15c313f000
> /*** It wasn't corrupted before the dma write
> /*** DMA a packet of length 0x5aa containing '0x61616161...' to guestOS at address 0x12ffac2 (which maps to 0x7f15c313eac2)
> dma write to 12ffac2 len 5aa
> xen_map_cache want 0x12ffac2
> xen_map_cache_return 0x7f15c313eac2
> /*** Check if guestOS address 0xe00000 (which maps to 0x7f15c313f000) is corrupted
> xen_map_cache want 0xe00000
> xen_map_cache_return 0x7f15c313f000
> /*** It is corrupted now.
> e1000: Corrupted 7: test_buf:5aa 5aa
> 

> The DMA address 0x12ffac2 mapped to 0x7f15c313eac2.  When you add the
> packet length, 0x5aa, the result is 0x7f15c313f06c.  This result is 0x6c
> bytes into the mapping of guestOS address 0xe00000, which mapped to
> 0x7f15c313f000.  If you dump 0xe00000 in the guestOS, 0x6c bytes are
> corrupted.

> We believe that the correct fix is to use qemu_ram_ptr_length instead of
> qemu_get_ram_ptr in the function address_space_rw to ensure (from what
> we can tell) that the mapped address is valid for the entire length
> specified.  It looked like this might also be an issue in
> cpu_physical_memory_write_rom so we made the change there as well.
> 


Corrupted DMA buffer is 0x e00000 -- 0x7f15c313f000.
The e1000 packet is at  0x12ffac2 -- 0x7f15c313eac2.

(0x7f15c313f000 - 0x7f15c313eac2) = 0x53e which is less than 0x5aa and
(0x5aa - 0x53e) = 0x6c bytes get corrupted.

I see here buffer overrun from e1000 and I suspect that your patch just
hides this problem. What did I miss?

Does e1000 still work with the patch applied? Are all 100% packets
delivered fine?




> We are fairly new to the qemu source base so we are looking to the
> community to see if this problem has previously been identified and to
> see if this is the correct fix.
> 


> Following is the patch
> 
> --- orig/exec.c 2013-11-27 16:52:55.000000000 -0600
> +++ new/exec.c  2014-02-15 21:58:34.311518000 -0600
> @@ -1911,7 +1911,7 @@
>              } else {
>                  addr1 += memory_region_get_ram_addr(mr);
>                  /* RAM case */
> -                ptr = qemu_get_ram_ptr(addr1);
> +                ptr = qemu_ram_ptr_length(addr1, &l);
>                  memcpy(ptr, buf, l);
>                  invalidate_and_set_dirty(addr1, l);
>              }
> @@ -1945,7 +1945,7 @@
>                  }
>              } else {
>                  /* RAM case */
> -                ptr = qemu_get_ram_ptr(mr->ram_addr + addr1);
> +                ptr = qemu_ram_ptr_length(mr->ram_addr + addr1, &l);
>                  memcpy(buf, ptr, l);
>              }
>          }
> @@ -1995,7 +1995,7 @@
>          } else {
>              addr1 += memory_region_get_ram_addr(mr);
>              /* ROM/RAM case */
> -            ptr = qemu_get_ram_ptr(addr1);
> +            ptr = qemu_ram_ptr_length(addr1, &l);
>              memcpy(ptr, buf, l);
>              invalidate_and_set_dirty(addr1, l);
>          }
> 
> 
> David Hoyer
> Controller Firmware Development
> Array Products Group
> 
> NetApp
> 3718 N. Rock Road
> Wichita, KS 67226
> 316-636-8047 phone
> 316-617-3677 mobile
> David.Hoyer@netapp.com<mailto:David.Hoyer@lsi.com>
> netapp.com<http://www.netapp.com/?ref_source=eSig>
> 
>  [Description: http://media.netapp.com/images/netapp-logo-sig-5.gif]
> 
> 

Alexey