Re: [lwip-devel] in-place overwriting of payload via static "tcphdr" pointer.

[Bernhart Pelger]

Am 10.01.2018 um 15:21 schrieb Simon Goldschmidt:
> Bernhart Pelger wrote:
> > > > I know this sounds fundamentally broken, because other arriving packets
> > > > might be overwriting the free'd DMA buffers before LWIP or the
> > > > application had a chance to process it.
> > > This does not *sound* fundamentally broken, it *is*!
> > But that's a different topic, not in the scope of this topic, or even
> > this mailing list.
> > And it doesn't affect me right now with my usage pattern.
> It's a different topic, yes. I'm not 100% sure though that it doesn't
> affect you. If you see cache issues now, how far away is an overwritten
> packet?
Well I have no cache issues at all, when I flush the cache line 
containing the tcp header.
This cache line contains the last few bytes from the IP header, the full 
TCP header, and a few (4?) bytes of payload data.

When I don't flush that cache line, under heavy rx traffic, once every 
10 minutes or so I do get
corrupted packets. When I inspect them in the debugger I see 
byte-flipped port numbers in the tcp header
and the first few bytes corrupted in the payload (probably leftover data 
from the last processed packet).

It looks like this: (Y marks the cache line, X marks corruption, view 
with fixed-width-font)
|--ETH---|---IP---|---TCP---|----------payload-------|
|--ETH---|---IP--YYYYYYYYYYYYYY--------payload-------|
|--ETH---|---IP---|--XXXXXXXXXX--------payload-------|

It can't get any clearer than that: it's the write access to the tcp 
header (the IP header would also be
corrupted, but you can't see that because the destination IP is the same 
for previous and current packet)

As for the other bug in the Xilinx driver (freeing the DMA buffers too 
early):
With my current network configuration I should run into 
overwrite-problems after about 6ms to 10ms (at max rate RX traffic).
However since I'm not using an operating system, it *is* possible to 
guarantee that the netif-function is called frequently enough.

Also the test environment for that bug would be a bit harder, because 
when polling too slow we always lose packets.
So we have to destinguish between normal packet loss and actually 
overwritten packets.

Regards, Bernhart.

> Simon
>
> _______________________________________________
> lwip-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-devel


--
--
Bernhart Pelger-Alzner
Entwicklungsingenieur Software
Tel:    +49 89 201804-261
Fax:    +49 89 201804-100
E-Mail: address@hidden

ASTYX GmbH
Lise-Meitner-Str. 2a, 85521 Ottobrunn, Germany
Postfach 1248, 85504 Ottobrunn, www.astyx.de
Reg.Nr.: München HRB 116 461, VAT: DE 186 893 572
CEO: Dipl.-Ing. G. Trummer