lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <57722AC0.7090003@huawei.com>
Date:	Tue, 28 Jun 2016 15:44:00 +0800
From:	Tan Xiaojun <tanxiaojun@...wei.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
CC:	<davem@...emloft.net>, <kuznet@....inr.ac.ru>, <jmorris@...ei.org>,
	<yoshfuji@...ux-ipv6.org>, <kaber@...sh.net>,
	<aduyck@...antis.com>, <hkchu@...gle.com>,
	<netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: IP ID check (flush_id) in inet_gro_receive is necessary or not?

On 2016/6/28 12:57, Eric Dumazet wrote:
> On Tue, 2016-06-28 at 12:40 +0800, Tan Xiaojun wrote:
>> Hi everyone,
>>
>> 	I'm sorry to bother you. But I was confused.
>>
>> 	The IP ID check (flush_id) in inet_gro_receive is only used by
>> tcp_gro_receive, and in tcp_gro_receive we have tcphdr check to ensure
>> the order of skbs,
>> 	like below:
>>
>> 	flush |= (__force int)(th->ack_seq ^ th2->ack_seq);
>> 	flush |= (ntohl(th2->seq) + skb_gro_len(p)) ^ ntohl(th->seq);
>>
>> 	So if I remove the IP ID check in inet_gro_receive, there will be a
>> problem ? And under what circumstances ?
> 
> You probably missed a recent patch ?
> 

Thank you very much. 

Is this patch means forcing the IP ID to be incrementing by 1 is necessary in the
case of using tunnel (if the IP_DF is not set in frag_off).

I have not used the tunneled frames. Do you have some examples for that ?

Xiaojun.

> commit 1530545ed64b42e87acb43c0c16401bd1ebae6bf
> Author: Alexander Duyck <aduyck@...antis.com>
> Date:   Sun Apr 10 21:44:57 2016 -0400
> 
>     GRO: Add support for TCP with fixed IPv4 ID field, limit tunnel IP ID values
>     
>     This patch does two things.
>     
>     First it allows TCP to aggregate TCP frames with a fixed IPv4 ID field.  As
>     a result we should now be able to aggregate flows that were converted from
>     IPv6 to IPv4.  In addition this allows us more flexibility for future
>     implementations of segmentation as we may be able to use a fixed IP ID when
>     segmenting the flow.
>     
>     The second thing this does is that it places limitations on the outer IPv4
>     ID header in the case of tunneled frames.  Specifically it forces the IP ID
>     to be incrementing by 1 unless the DF bit is set in the outer IPv4 header.
>     This way we can avoid creating overlapping series of IP IDs that could
>     possibly be fragmented if the frame goes through GRO and is then
>     resegmented via GSO.
>     
>     Signed-off-by: Alexander Duyck <aduyck@...antis.com>
>     Signed-off-by: David S. Miller <davem@...emloft.net>
> 
> 
> 
> .
> 


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ