netdev - Re: [net-next PATCH v2 4/8] udp: Do not pass checksum as a parameter to GSO segmentation

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: <CAKgT0Ud1h1piFutr0gWkac3sEtB9fbOaW3MAphheazHtXUpbpw@mail.gmail.com>
Date:   Fri, 4 May 2018 15:28:38 -0700
From:   Alexander Duyck <alexander.duyck@...il.com>
To:     Eric Dumazet <eric.dumazet@...il.com>
Cc:     Netdev <netdev@...r.kernel.org>,
        Willem de Bruijn <willemb@...gle.com>,
        David Miller <davem@...emloft.net>
Subject: Re: [net-next PATCH v2 4/8] udp: Do not pass checksum as a parameter
 to GSO segmentation

On Fri, May 4, 2018 at 1:19 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
>
>
> On 05/04/2018 11:30 AM, Alexander Duyck wrote:
>> From: Alexander Duyck <alexander.h.duyck@...el.com>
>>
>> This patch is meant to allow us to avoid having to recompute the checksum
>> from scratch and have it passed as a parameter.
>>
>> Instead of taking that approach we can take advantage of the fact that the
>> length that was used to compute the existing checksum is included in the
>> UDP header. If we cancel that out by adding the value XOR with 0xFFFF we
>> can then just add the new length in and fold that into the new result.
>>
>
>>
>> +     uh = udp_hdr(segs);
>> +
>> +     /* compute checksum adjustment based on old length versus new */
>> +     newlen = htons(sizeof(*uh) + mss);
>> +     check = ~csum_fold((__force __wsum)((__force u32)uh->check +
>> +                                         ((__force u32)uh->len ^ 0xFFFF) +
>> +                                         (__force u32)newlen));
>> +
>
>
> Can't this use csum_sub() instead of this ^ 0xFFFF trick ?

I could but that actually adds more instructions to all this since
csum_sub will perform the inversion across a 32b checksum when we only
need to bitflip a 16 bit value. I had considered doing (u16)(~uh->len)
but thought type casing it more than once would be a pain as well.

What I wanted to avoid is having to do the extra math to account for
the rollover. Adding 3 16 bit values will result in at most a 18 bit
value which can then be folded. Doing it this way we avoid that extra
add w/ carry logic that is needed for csum_add/sub.