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

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

Date:   Wed, 12 Feb 2020 11:52:55 +0200
From:   Grygorii Strashko <grygorii.strashko@...com>
To:     netdev <netdev@...r.kernel.org>,
        "David S . Miller" <davem@...emloft.net>
CC:     Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>
Subject: CHECKSUM_COMPLETE question

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?

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