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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <7aa1271399664bb3ac453a7f4d64798e@AcuMS.aculab.com>
Date:   Fri, 3 Dec 2021 14:51:15 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Vladimir Oltean' <olteanv@...il.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()

From: Vladimir Oltean
> Sent: 02 December 2021 21:40
> 
> 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
...

Possibly because the rest of the packet actually has a valid checksum
(ie 0xffff) that (somewhere) got reduced to 16 bits.
If the checksum of the header were then added, and later removed
you'd end up inverting ~0u.

	David

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