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, 21 Feb 2014 19:08:53 -0800
From:	Tom Herbert <therbert@...gle.com>
To:	Dimitrios Michailidis <dm@...lsio.com>
Cc:	Linux Netdev List <netdev@...r.kernel.org>
Subject: Re: Does CHECKSUM_COMPLETE work at all?

On Fri, Feb 21, 2014 at 6:36 PM, Dimitrios Michailidis <dm@...lsio.com> wrote:
> Tom Herbert wrote:
>> If a driver sets CHECKSUM_COMPLETE in a packet, I don't see anywhere
>> in either the Ethernet rcv path or ip_rcv where the skb->csum is being
>> pulled (no *pull_rcsum calls). I believe CHECKSUM_COMPLETE means the
>> checksum is over the whole packet (L2, L3, and L4), so it looks like
>> TCP would never see a usable value.
>>
>> Is this interpretation correct? There's only a handful of drivers
>> providing CHECKSUM_COMPLETE can anyone who has access verify this?
>
> AFAIK CHECKSUM_COMPLETE means the checksum is calculated over the L4 part of the frame but doesn't include the pseudoheader. It is completed by adding the pseudoheader.  I use it this way and it works.
>
>From skbuff.h:

"The device supplied checksum of the _whole_packet as seen by
netif_rx() and fills out in skb->csum. Meaning, the hardware doesn't
need to parse L3/L4 headers to implement this."

> By any chance are you asking this in the context of tunneling and how to get both the inner and outer checksums from the value the HW calculates?
>
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! :-)

>>
>> Thanks,
>> Tom
>
--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ