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

[Alexey Kardashevskiy <aik@ozlabs.ru>]

On 03/04/2014 08:33 AM, Don Slutz wrote:
> On 03/03/14 05:47, Alexey Kardashevskiy wrote:
>> On 03/03/2014 07:33 PM, Paolo Bonzini wrote:
>>> Il 03/03/2014 02:58, Alexey Kardashevskiy ha scritto:
>>>> On 03/02/2014 08:31 AM, Paolo Bonzini wrote:
>>>>> Il 01/03/2014 13:30, Alexey Kardashevskiy ha scritto:
>>>>>>>> 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?
>>>>>> Ping, anyone?
>>>>> You missed that this is a Xen-specific problem.  Xen maps things a
>>>>> page at
>>>>> a time, so address_space_map/unmap/rw can operate only on a small part of
>>>>> the requested [address, address+length) range.
>>>> Sorry, I am not following you here. Does KVM map things not page-aligned?
>>> Look in exec.c for xen_enabled().  Xen's implementation of
>>> address_space_map/unmap is completely different.
>> Honestly cannot see much difference in the current QEMU...
>>
>>>>> So there is no overrun in e1000.  The patch is incomplete, because it
>>>>> fixes
>>>>> only address_space_rw, but the problem is indeed in exec.c.
>>>> So you know what the problem is? We have a bunch of bugreports against
>>>> e1000 breaking things...
>>> This one had been reported and fixed already.
>> Any hint? :) Could not spot any related to overrun except:
>> a0ae17a 8 months ago Andrew Jones e1000: cleanup process_tx_desc
>> but commit message says "complaints are false positives"...
>>
>>
> 
> Looks like you have also ignored:
> 
> http://marc.info/?l=qemu-devel&m=139325054822857&w=2
> http://marc.info/?l=qemu-devel&m=139325135123159&w=2

Oh, thanks!



-- 
Alexey