netdev - Re: [PATCH net-next 6/8] net: gre: Implement LCO for GRE over IPv4

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: <CAKgT0Ufpj2DpaLPOzU5hyFATpjN=jT9ziJCpmSMo1QkefAcAKQ@mail.gmail.com>
Date:	Wed, 20 Jan 2016 11:35:20 -0800
From:	Alexander Duyck <alexander.duyck@...il.com>
To:	"Rustad, Mark D" <mark.d.rustad@...el.com>
Cc:	Edward Cree <ecree@...arflare.com>,
	David Laight <David.Laight@...lab.com>,
	David Miller <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-net-drivers@...arflare.com" <linux-net-drivers@...arflare.com>,
	"tom@...bertland.com" <tom@...bertland.com>
Subject: Re: [PATCH net-next 6/8] net: gre: Implement LCO for GRE over IPv4

On Wed, Jan 20, 2016 at 11:11 AM, Rustad, Mark D
<mark.d.rustad@...el.com> wrote:
> Alexander Duyck <alexander.duyck@...il.com> wrote:
>
>> Actually you may want to go the other way on that.  If they weren't
>> flipping the checksum value for GRE before why should we start doing
>> that now?  I'm pretty sure the checksum mangling is a very UDP centric
>> thing.  There is no need to introduce it to other protocols.
>
>
> If different checksum representations are needed, then there really should
> be an explicit indication of whether it is a UDP-style checksum or other in
> the skb I would think rather than guessing it based on the offset. Of course
> it would be convenient if all the protocols that use a one's complement
> checksum would tolerate the UDP representation. I have a long (and now old)
> history working with real one's complement machines, and so I would want to
> believe that any correct implementation would tolerate it, but I don't know
> for a fact that they do.

The only reason why UDP does the bit flip is because it has reserved a
checksum of 0 as a special value.  For the checksum math itself either
0xFFFF or 0 are interchangeable.  The only time they would make any
difference would be if we had a value of 0 that we were checksumming,
but since that is not the case the values will always end up
converging back onto 0xFFFF as the final result in the case of a
correct checksum.

- Alex