netdev - Re: [PATCH net-next 2/2] net: optimize skb_postpull

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 2 Dec 2021 23:40:09 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     David Laight <David.Laight@...LAB.COM>
Cc:     Eric Dumazet <edumazet@...gle.com>,
        Eric Dumazet <eric.dumazet@...il.com>,
        "David S . Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 2/2] net: optimize skb_postpull_rcsum()

On Thu, Dec 02, 2021 at 08:58:46PM +0000, David Laight wrote:
> > To me it looks like the strange part is that the checksum of the removed
> > block (printed by me as "csum_partial(start, len, 0)" inside
> > skb_postpull_rcsum()) is the same as the skb->csum itself.
> 
> If you are removing all the bytes that made the original checksum
> that will happen.
> And that might be true for the packets you are building.

Yes, I am not removing all the bytes that made up the original L2
payload csum. Let me pull up the skb_dump from my original message:

                        here is where the enetc saw the          the "start" variable (old skb->data)
                        beginning of the frame                   points here
                        v                                         v
skb headroom: 00000040: 88 80 00 0a 00 33 9d 40 f0 41 01 80 00 00 08 0f

                              OCELOT_TAG_LEN bytes into the frame,
                              the real MAC header can be found
                                    v
skb headroom: 00000050: 00 10 00 00 00 04 9f 05 f6 28 ba ae e4 b6 2c 3d
skb headroom: 00000060: 08 00
skb linear:   00000000: 45 00 00 54 27 ac 00 00 40 01 09 a8 c0 a8 64 03
                        ^
                        the skb_postpull_rcsum is called from "start"
                        pointer until the first byte prior to this one

skb linear:   00000010: c0 a8 64 01 00 00 10 e6 01 5c 00 04 49 30 a7 61
skb linear:   00000020: 00 00 00 00 3d 55 01 00 00 00 00 00 10 11 12 13
skb linear:   00000030: 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23
skb linear:   00000040: 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33
skb linear:   00000050: 34 35 36 37

So skb_postpull_rcsum() is called from "skb headroom" offset 0x4e to
offset 0x61 inclusive (0x61 - 0x4e + 1 = 20 == OCELOT_TAG_LEN).

However as I understand it, the CHECKSUM_COMPLETE of this packet is
calculated by enetc from "skb headroom" offset 0x4e and all the way
until "skb linear" offset 0x53. So there is still a good chunk of packet
to go. That's why it is still a mystery to me why the checksums would be
equal. They still are, with your change suggested below, of course, but
at least there is no splat now.

> 
> Try replacing both ~ with -.
> So replace:
> 		skb->csum = ~csum_partial(start, len, ~skb->csum);
> with:
> 		skb->csum = -csum_partial(start, len, -skb->csum);
> 
> That should geneate ~0u instead 0 (if I've got my maths right).

Indeed, replacing both one's complement operations with two's complement
seems to produce correct results (consistent with old code) in all cases
that I am testing with (ICMP, TCP, UDP). Thanks!

> 
> 	David
> 
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)
>