netdev - Re: Does CHECKSUM_COMPLETE work at all?

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

Message-ID: <CA+mtBx8xGmZvZU+P4Uy6q3TxWdOgK3-ke9Ccfx3=xRS2-ygSQA@mail.gmail.com>
Date:	Sat, 22 Feb 2014 09:32:03 -0800
From:	Tom Herbert <therbert@...gle.com>
To:	Daniel Borkmann <dborkman@...hat.com>
Cc:	Dimitrios Michailidis <dm@...lsio.com>,
	Linux Netdev List <netdev@...r.kernel.org>,
	Stephen Hemminger <stephen@...workplumber.org>
Subject: Re: Does CHECKSUM_COMPLETE work at all?

On Sat, Feb 22, 2014 at 4:42 AM, Daniel Borkmann <dborkman@...hat.com> wrote:
> On 02/22/2014 04:08 AM, Tom Herbert wrote:
> ...
>
>> Well..., I started trying to fix the UDP encapsulation code which we
>> agreed was broken for checksums. This also entails fixing the new UDP
>> GRO code to deal with checksums correctly when going through protocol
>> layers. But, just looking at CHECKSUM_COMPLETE it seems like it's
>> fundamentally broken even without encapsulation. Between GRO and HW
>> checksums, it seems like we have a pretty big mess! :-)
>
>
> Seems so, e.g. d97c00a32198 ("vxlan: fix receive checksum handling")
> had similar issues in that regard; maybe because there seems to be
> different consensus among drivers on setting CHECKSUM_COMPLETE?

There shouldn't be, the requirements are pretty clear in the
description of CHECKSUM_COMPLETE. However, the meaning of
CHECKSUM_UNNECESSARY is ambiguous. Checksum offload for simple TCP or
UDP packets is fairly straightforward, but as devices support other
protocols and combinations of encapsulations correctness becomes
suspect. The problem is that the host can't verify
CHECKSUM_UNNECESSARY, so if it's not right or there is not agreement
between host and device as to which checksums are covered, then
packets can received with bad checksums. This will be really hard to
debug! As the comments about CHECKSUM_UNNECESSARY say "It is a bad
option" :-)

I think the fix for CHECKSUM_COMPLETE is to hold the start and length
of the data pertaining skb->csum. This way we only need to pull the
checksum when actually verifying it (don't want to pull it at every
header pull). This also relaxes the requirement that the device
provides the checksum for the whole packet, it could instead provide
partial coverage (there's really no need to have Ethernet header
checksummed for instance). No where in the stack should we be changing
CHECKSUM_COMPLETE to CHECKSUM_UNNECESSARY (that is a demotion), also
we should never be folding pseudo header checksum into skb->csum.
--
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