netdev - Re: [PATCH v2 net-next 3/5] net: vxlan: enable local checksum offload

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]

Date:	Fri, 8 Jan 2016 13:22:47 -0800
From:	Alexander Duyck <alexander.duyck@...il.com>
To:	Jesse Gross <jesse@...nel.org>
Cc:	Edward Cree <ecree@...arflare.com>,
	David Miller <davem@...emloft.net>,
	Netdev <netdev@...r.kernel.org>,
	linux-net-drivers@...arflare.com, Tom Herbert <tom@...bertland.com>
Subject: Re: [PATCH v2 net-next 3/5] net: vxlan: enable local checksum offload

On Fri, Jan 8, 2016 at 11:40 AM, Jesse Gross <jesse@...nel.org> wrote:
> On Fri, Jan 8, 2016 at 10:03 AM, Alexander Duyck
> <alexander.duyck@...il.com> wrote:
>> On Fri, Jan 8, 2016 at 7:39 AM, Edward Cree <ecree@...arflare.com> wrote:
>>> On 08/01/16 03:46, Alexander Duyck wrote:
>>>> So I just tried testing your patches and as it turns out you are still
>>>> missing some bits.  In this patch for instance the calls to
>>>> udp_tunnel_xmit_skb and udp_tunnel6_xmit skb need to be updated so
>>>> that you pass false for the last parameter and allow the use of your
>>>> udp_set_csum modifications.
>>>>
>>>> - Alex
>>> Are you remembering to enable outer checksums on your vxlan tunnel?  It's
>>>  the vxflags & VXLAN_F_UDP_CSUM check, and to enable it you need a recent
>>>  iproute2 so you can use the 'udpcsum' option when creating the vxlan device.
>>
>> No I hadn't done that.  I kind of assumed that the checksums were just
>> being enabled by default.  That might explain the some of the issues I
>> had..  ;-)
>>
>>> It would be nice if that could just default to enabled now that we have LCO,
>>>  but I don't think we can change that now (ABIs set in stone and all that),
>>>  so I think it would have to be iproute2 that turned it on by default.
>>
>> If anything we might want to expose the capabilities of the kernel so
>> that iproute2 could make an informed decision on if it want to enable
>> the outer checksum by default or not.
>
> Keep in mind that protocols like VXLAN specify that the UDP checksum
> should be set to zero. As a result, enabling the checksum is not a
> purely local decision and it probably shouldn't be on by default.

Yes, but the RFC allows for a non-zero checksum.  The key difference
here is the wording between SHOULD and MUST.  We aren't requiring the
other endpoint to enable outer checksum on its end, and we don't
require the remote end to validate the outer checksum.  We have made
that purely optional.  If however the other end is also a Linux client
it can make use of the outer checksum and hardware offloads to greatly
improve the performance.

It is essentially all the goodness of remote checksum offload without
the compatibility negatives, assuming of course everyone implemented
things according to the RFC and didn't make the 0 checksum mandatory..