netdev - Re: CHECKSUM_COMPLETE question

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]

Message-ID: <9cfc1bcb-6d67-e966-28d9-a6f290648cb0@ti.com>
Date:   Wed, 19 Feb 2020 19:03:44 +0200
From:   Grygorii Strashko <grygorii.strashko@...com>
To:     netdev <netdev@...r.kernel.org>,
        "David S . Miller" <davem@...emloft.net>,
        Alexey Kuznetsov <kuznet@....inr.ac.ru>,
        Eric Dumazet <edumazet@...gle.com>,
        John Fastabend <john.fastabend@...il.com>
CC:     Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>
Subject: Re: CHECKSUM_COMPLETE question

Hi All,

On 12/02/2020 11:52, Grygorii Strashko wrote:
> Hi All,
> 
> I'd like to ask expert opinion and clarify few points about HW RX checksum offload.
> 
> 1) CHECKSUM_COMPLETE - from description in <linux/skbuff.h>
>   * CHECKSUM_COMPLETE:
>   *
>   *   This is the most generic way. 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.
> 
> My understanding from above is that HW, to be fully compatible with Linux, should produce CSUM
> starting from first byte after EtherType field:
>   (6 DST_MAC) (6 SRC_MAC) (2 EtherType) (...                   ...)
>                                          ^                       ^
>                                          | start csum            | end csum
> and ending at the last byte of Ethernet frame data.
> - if packet is VLAN tagged then VLAN TCI and real EtherType included in CSUM,
>    but first VLAN TPID doesn't
> - pad bytes may/may not be included in csum
> 
> 
> 2) I've found some difference between IPv4 and IPv6 csum processing of fragmented packets
> 
> Fragmented IPv4 UDP packet:
>   - driver fills skb->csum and sets skb->ip_summed = CHECKSUM_COMPLETE for every fragment
>   - in ip_frag_queue() the ip_hdr is parsed, and polled, and packet queued, but
>     there is *no* csum correction in this function for polled ip_hdr (no csum_sub() or similar calls)
> ^^^^
>   - as result, in inet_frag_reasm_finish() the skb->csum field can be seen unmodified
>   - if the same packet is sent over VLAN the skb->csum in inet_frag_reasm_finish() will be seen as modified due to
>     skb_vlan_untag()->skb_pull_rcsum()
> 
> Fragmented IPv6 UDP packet:
>   - driver fills skb->csum and sets skb->ip_summed = CHECKSUM_COMPLETE for every fragment
>   - in ip6_frag_queue() the ipv6_hdr s parsed, and polled, and packet queued,
>     *and csum corrected*
> 
>   ip6_frag_queue()
>   ...
>          if (skb->ip_summed == CHECKSUM_COMPLETE) {
>          const unsigned char *nh = skb_network_header(skb);
>          skb->csum = csum_sub(skb->csum,
>                       csum_partial(nh, (u8 *)(fhdr + 1) - nh,
> 
> Are there any reasons for such difference between IPv4 and IPv6?

I'm very sorry for disturbing you, but could anybody help with above two questions?


> 
> 3) few words about new HW i'm working with.
> The HW can parse IP4/IP6 and UDP/TCP headers and generate csum including pseudo header checksum
> which is working pretty well for non fragmented packets.
> 
> For fragmented packets (UDP for example):
> - First fragments have the UDP header (including pseudo header) and data included in the count.
> - Middle and last fragments have only data included in the count
> 
> As result when SUM_ALL(frag->csum) == 0xFFFF means packet csum is correct.
> 
> Above seems will not be working out of the box, at least not without csum manipulations simialar
> to what is done in mellanox/mlx4/en_rx.c (check_csum(),get_fixed_ipv4_csum(), get_fixed_ipv6_csum())
> 
> 
> Thanks you.
> 

-- 
Best regards,
grygorii