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: <B5657A6538887040AD3A81F1008BEC63B417B6@avmb3.qlogic.org>
Date:	Wed, 1 Oct 2014 05:17:27 +0000
From:	Yuval Mintz <Yuval.Mintz@...gic.com>
To:	"Tom Herbert (Partner - google)" <therbert@...gle.com>
CC:	Eric Dumazet <eric.dumazet@...il.com>,
	netdev <netdev@...r.kernel.org>
Subject: RE: How exactly does CHECKSUM_COMPLETE works?

> > 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.
> 
> But it does, as you pointed out the checksum calculation was performed over
> the whole payload. The fact that the computed checksum equals the one's
> complement of pseudo header is the indication that the checksum is valid. If
> there were a bit corruption, the computed value would be different (summing in
> pseudo header checksum would result in non-zero value).

Thanks, I've already reached that conclusion myself
[even wrote an E-mail; but it got blocked for some reason].