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  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:	Sat, 27 Sep 2014 23:39:30 +0300
From:	Or Gerlitz <>
To:	Tom Herbert <>
Cc:	David Miller <>,
	"" <>
Subject: Re: [PATCH v3 5/7] net: Add GSO support for UDP tunnels with checksum

On Sat, Sep 27, 2014 at 12:57 AM, Tom Herbert <> wrote:
> On Fri, Sep 26, 2014 at 2:05 PM, Or Gerlitz <> wrote:
>> On Thu, Jun 5, 2014 at 3:20 AM, Tom Herbert <> wrote:

>>> Added a new netif feature for GSO_UDP_TUNNEL_CSUM. This indicates
>>> that a device is capable of computing the UDP checksum in the
>>> encapsulating header of a UDP tunnel.

>> Do we have upstream driver that supports GSO_UDP_TUNNEL_CSUM? did you
>> had such driver/patch while doing this patches? when a driver
>> advertizes that bit, should they look over the xmit path on the new
>> encap_hdr_csum bit?

> No, no, and encap_hdr_csum should only be set with

I'm still trying to dig the bigger picture w.r.t checksum of the outer
UDP packet from the patches -- if I got it right, once these patches
were picked upstream, there's a scheme where the kernel either
computes this checksum or let the device do that - when they advertize
NETIF_F_GSO_YYY_CSUM  and in that case
(skb->encap_hdr_csum == true) should be interpreted as a directive to
do that, right?

So what happens when the device isn't capable to compute that checksum
(e.g they don't set _GSO_UDP_TUNNEL_CSUM) but they do advertize the

I was worried that we can run into this scheme - the stack computes
the outer checksum for the giant 64K UDP chunck that encapsulate a 64K
TCP segment, but when the NIC will issue the segmentation, they will
likely to just repeat ~40 times (64K/1500) the original udp checksum
for the packets they send, which will be treated as bad checksum on
the receiving end, bad.

> find . -name '*.[ch]' -exec fgrep -l GSO_UDP_TUNNEL_CSUM {} \;
> returns nothing.

grepping I know, I was just hoping you were able to test such a sensitive change
with HW that cause both code parts (outer udp checksum offloaded vs.
non-offloaded) to be exercised

> find . -name '*.[ch]' -exec fgrep -l GSO_UDP_TUNNEL {} \;
> returns
> ./ethernet/intel/i40e/i40e_main.c
> ./ethernet/broadcom/bnx2x/bnx2x_main.c
> ./ethernet/qlogic/qlcnic/qlcnic_main.c
> ./ethernet/mellanox/mlx4/en_netdev.c
> ./ethernet/emulex/benet/be_main.c

cool, I see here four 40Gbs NICs that support GSO offloading of VXLAN
traffic, each of them can serve you for testing new developments you
do in that area.

To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists