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 for Android: free password hash cracker in your pocket

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

Message-ID: <B5657A6538887040AD3A81F1008BEC63B415CB@avmb3.qlogic.org>
Date:	Tue, 30 Sep 2014 20:32:44 +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?

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

Or looking back on the IPv4/TCP scenario, what exactly is the csum
now protecting?
Assume the HW passes the one's complement sum of the entire data,
IP header and onward to driver, which sets it in SKB->csum and marks
the SKB as CHECKSUM_COMPLETE.
In practice, SKB->csum should now equal to the one's complement of
the TCP pseudo header; But other than the length of data in the TCP
header and payload that pseudo-header doesn't include any
information about the payload itself.
If we're willing to accept the payload [and the correctness of the
header while we're at it] based solely on this, what guarantee do we
have that the TCP checksum is actually correct? 
Seems like the only thing we've guaranteed is that nothing switched in
IP header since packet passed the HW - but we've already got that
covered by the IPv4 layer.

[I assume I'm missing something elementary here. Same as before ;-)]--
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