netdev - RE: How exactly does CHECKSUM

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <B5657A6538887040AD3A81F1008BEC63B4159B@avmb3.qlogic.org>
Date:	Tue, 30 Sep 2014 20:19:05 +0000
From:	Yuval Mintz <Yuval.Mintz@...gic.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
CC:	"Tom Herbert (Partner - google)" <therbert@...gle.com>,
	netdev <netdev@...r.kernel.org>
Subject: RE: How exactly does CHECKSUM_COMPLETE works?

> > Can you pinpoint me to what exactly in the code corrects NAPI_GRO_CB(skb)->csum
> > by negating the ipv4 part in the ones' complete checksum?
> >
> > E.g., for ipv6 [in ipv6_gro_receive()] I can see that skb_gro_postpull_rcsum() is
> > called after pulling the ipv6 header [and before proceeding to the next protocol],
> > but I can't seem to find anything similar to this for ipv4 [in inet_gro_receive()].
> >
>
>
> IPv4 header is supposed to have a 0 checksum ;)
>

Oops. Sorry, you're right.

But this is a bit strange.

I mean, if I go back to the IP-GRE case [with GRE checksum], the IP
csum negates the rest of the IP header and the GRE csum negates
everything else [GRE header, inner headers and payload].
So the mechanism might work as-is, but all the driver has to
do in order to claim that an IP-gre packet with checksum option is
CHECKSUM_COMPLETE is to write 0xffffffff on the skb's csum field.
 --
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html