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: <CA+mtBx8mt5qez5X5tPF_3S+0p2svmLScmxBvXziBYT9XTJ+w0w@mail.gmail.com>
Date:	Tue, 30 Sep 2014 22:15:56 -0700
From:	Tom Herbert <therbert@...gle.com>
To:	Yuval Mintz <Yuval.Mintz@...gic.com>
Cc:	Eric Dumazet <eric.dumazet@...il.com>,
	netdev <netdev@...r.kernel.org>
Subject: Re: How exactly does CHECKSUM_COMPLETE works?

On Tue, Sep 30, 2014 at 1:32 PM, Yuval Mintz <Yuval.Mintz@...gic.com> wrote:
>>> 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.

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

> 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 ;-)]

I think your assumption is correct ;-) You might want to take a look
at some of the RFCs that describe checksum verification with pseudo
header.
--
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