netdev - GRO disabled with IPv4 options

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <dd704f4a-f594-2965-36af-28df0c8e322e@cs.umu.se>
Date:   Thu, 16 Nov 2017 16:12:43 +0100
From:   Cristian Klein <cklein@...umu.se>
To:     netdev@...r.kernel.org
Cc:     herbert@...dor.apana.org.au, Ahmed Ali-Eldin <ahmeda@...umu.se>
Subject: GRO disabled with IPv4 options

[CC-ing Herbert Xu, who is to 'git blame' for the code in question. :)]

Dear all,

We are working on a research prototype which, among others, adds a new 
IPv4 option. During testing we noticed that the packets captured by 
tcpdump shrank from 10s of KBs to the MTU, which indicates that Generic 
Receive Offload (GRO) got disabled.

Upon further investigation, we found the following line in 
`inet_gro_receive`:

	if (*(u8 *)iph != 0x45)
		goto out_unlock;

in plain English, don't do GRO if any IPv4 options are present.

Does somebody know the rationale for this? Is it because IPv4 options 
are rarely used, hence implementing GRO in that case does not pay off or 
are there some caveats? Specifically would it make sense to do GRO when 
the IPv4 options are byte-identical in consecutive packets?

Regards,

-- 
Cristian Klein, PhD
Researcher @ Umeå University
http://kleinlabs.eu