netdev - Re: Confused about ip_summed member in sk

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: <d309d044-6e9f-e722-6d75-46b174736cc2@gmail.com>
Date:   Tue, 8 Nov 2022 17:12:58 +0000
From:   Edward Cree <ecree.xilinx@...il.com>
To:     "J.J. Mars" <mars14850@...il.com>,
        Cong Wang <xiyou.wangcong@...il.com>
Cc:     netdev@...r.kernel.org
Subject: Re: Confused about ip_summed member in sk_buff

On 08/11/2022 12:32, J.J. Mars wrote:
> Thanks for your reply. I've been busy these days so that I can't reply on time.
> I've read the annotation about ip_summed in skbuff.h many times but it
> still puzzles me so I write my questions here directly.
> 
> First of all, I focus on the receive direction only.
> 
> Q1: In section 'CHECKSUM_COMPLETE' it said '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.' So I assume the 'device' is a nic or something
> like that which supplied checksum, but the 'hardware' doesn't need to
> parse L3/L4 headers. So what's the difference between 'device' and
> 'hardware'? Which one is the nic?

Both.
To implement this feature, the NIC is supposed to treat the packet data
 as an unstructured array of 16-bit integers, and compute their (ones-
 complement) sum.
When the kernel parses the packet headers, it will subtract out from
 this sum the headers it consumes, and then check that what's left over
 matches the sum of the L4 pseudo header (as it should for a correctly
 checksummed packet).
Note that this design means protocol parsing happens only in software,
 with the NIC completely protocol-agnostic; thus upgrades to support
 new protocols only require a kernel upgrade and not a new NIC.

> Q2: Which layer does the checksum refer in section 'CHECKSUM_COMPLETE'
> as it said 'The device supplied checksum of the _whole_ packet'. I
> assume it refers to both L3 and L4 checksum because of the word
> 'whole'.

See above - the device is not supposed to know or care where L3 or L4
 headers start or where their checksum fields live, it just sums the
 whole thing, and the kernel mathematically derives the sum of the L4
 payload from that.

> Q3: The full checksum is not calculated when 'CHECKSUM_UNNECESSARY' is
> set. What does the word 'full' mean? Does it refer to both L3 and L4?
> As it said 'CHECKSUM_UNNECESSARY' is set for some L4 packets, what's
> the status of L3 checksum now? Does L3 checksum MUST be right when
> 'CHECKSUM_UNNECESSARY' is set?

'full' here refers to the CHECKSUM_COMPLETE sum described above.
CHECKSUM_UNNECESSARY refers to the L4 checksum, and may be set by the
 driver when the hardware has determined that the L4 checksum is
 correct.  This is an inferior hardware design because it can only
 support those specific protocols the hardware understands; but we
 handle it in the kernel because lots of hardware like that exists :(
L3 checksums are never offloaded to hardware (neither by
 CHECKSUM_COMPLETE nor by CHECKSUM_UNNECESSARY); because they only
 sum over the L3 header (not its payload), they are cheap to compute
 in software (the costly bit is actually bringing the data into cache,
 and we have to do that anyway to parse the header, so summing it at
 the same time is almost free).
AFAIK a driver may set CHECKSUM_UNNECESSARY even if the L3 checksum is
 incorrect, because it only covers the L4 sum; but I'm not 100% sure.

> Q4: In section 'CHECKSUM_PARTIAL' it described status of SOME part of
> the checksum is valid. As it said this value is set in GRO path, does
> it refer to L4 only?

Drivers should not use CHECKSUM_PARTIAL on the RX side; only on TX
 (for which see [1] for additional documentation).

> Q5: 'CHECKSUM_COMPLETE' and 'CHECKSUM_UNNECESSARY', which one supplies
> the most complete status of checksum? I assume it's
> CHECKSUM_UNNECESSARY.

CHECKSUM_COMPLETE is preferred, as per above remarks about protocols.

> Q6: The name ip_summed doesn't describe the status of L3 only but also
> L4? Or just L4?

Just L4.  It's called "ip_summed" because the "16-bit ones-complement
 sum" style of checksum is also known as the "Internet checksum"
 since it is used repeatedly in the Internet protocol suite, such as
 in TCP and UDP as well as IPv4.  Yes, this is confusing, but it's
 too late to rename it now.

HTH,
-ed

[1] https://www.kernel.org/doc/html/latest/networking/checksum-offloads.html#tx-checksum-offload