netdev - Re: [PATCH net-next] udp: Avoid post-GRO UDP checksum recalculation

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, 24 May 2019 14:50:45 +0200
From:   Paolo Abeni <pabeni@...hat.com>
To:     Sean Tranchetti <stranche@...eaurora.org>, davem@...emloft.net,
        netdev@...r.kernel.org
Cc:     Subash Abhinov Kasiviswanathan <subashab@...eaurora.org>
Subject: Re: [PATCH net-next] udp: Avoid post-GRO UDP checksum recalculation

On Thu, 2019-05-23 at 13:36 -0600, Sean Tranchetti wrote:
> Currently, when resegmenting an unexpected UDP GRO packet, the full UDP
> checksum will be calculated for every new SKB created by skb_segment()
> because the netdev features passed in by udp_rcv_segment() lack any
> information about checksum offload capabilities.
> 
> We have no need to perform this calculation again, as
>   1) The GRO implementation guarantees that any packets making it to the
>      udp_rcv_segment() function had correct checksums, and, more
>      importantly,
>   2) Upon the successful return of udp_rcv_segment(), we immediately pull
>      the UDP header off and either queue the segment to the socket or
>      hand it off to a new protocol handler. In either case, the checksum
>      is not needed.

I *think* there is a possible, even if unlikely, exception to the
above: if userspace has set the IP_CHECKSUM sockopt, recvmsg can later
try to access skb csum.

I think that setting NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM only if
!inet_get_convert_csum() would address the above,

Other than that LGTM, thanks for catching this!

Paolo

p.s. I suspect that with this patch GRO + resegmentation is notably
faster than the plain unaggregated path, do you have by chance any
related datapoint?