linux-kernel - Re: IP ID check (flush_id) in inet_gro

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]

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>
> 
> 
> 
> .
>