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: <B5657A6538887040AD3A81F1008BEC63B4152D@avmb3.qlogic.org>
Date:	Tue, 30 Sep 2014 19:05:05 +0000
From:	Yuval Mintz <Yuval.Mintz@...gic.com>
To:	"Tom Herbert (Partner - google)" <therbert@...gle.com>
CC:	netdev <netdev@...r.kernel.org>
Subject: RE: How exactly does CHECKSUM_COMPLETE works?

> > Scenario 1 - TCP/IPv4 packet. This will eventually reach
> > tcp4_gro_receive(), and from there into skb_gro_checksum_validate().
> > Since this SKB is marked as COMPLETE, the pseudo TCP checksum will be
> > computed and skb_gro_checksum_validate_complete() be called.
> > Now, it seems to me as if the only way by which the flow won't
> > actually try to re-calculate the checksum over TCP header and payload
> > is if NAPI_GRO_CB(skb)->csum is actually the one's complement to the
> > TCP pseudo header. But that sounds.... odd, since that's the csum that
> > should have been listed on the SKB - and it doesn't protect any of the data,
> only the "metadata".
> >
> With CHECKSUM_COMPLETE, on entrance into GRO NAPI_GRO_CB(skb)->csum
> is set to skb->csum. As the packet is parsed through various levels of GRO the
> value is adjusted so that at any header level it is the complete checksum starting
> from that header to the end of the packet.
> So to validate a TCP checksum we just need to add the value of the pseudo
> header checksum (a little computation) and compare to zero.

...

>> 1. What should a driver set as the SKBs csum value when passing CHECKSUM_COMPLETE?
>This ones complete checksum of the Ethernet payload (start of IP header to the end of the packet).

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()].

________________________________

This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.