From: David Laight <David.Laight@ACULAB.COM>
To: 'Al Viro' <viro@zeniv.linux.org.uk>
Cc: "linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
"gus Gusenleitner Klaus" <gus@keba.com>,
Al Viro <viro@ftp.linux.org.uk>,
"Thomas Gleixner" <tglx@linutronix.de>,
lkml <linux-kernel@vger.kernel.org>,
"Ingo Molnar" <mingo@redhat.com>, "bp@alien8.de" <bp@alien8.de>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"x86@kernel.org" <x86@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
"dsahern@kernel.org" <dsahern@kernel.org>,
"kuba@kernel.org" <kuba@kernel.org>,
Paolo Abeni <pabeni@redhat.com>,
Eric Dumazet <edumazet@google.com>
Subject: RE: [RFC][PATCHES v2] checksum stuff
Date: Thu, 7 Dec 2023 09:58:48 +0000 [thread overview]
Message-ID: <d7faa6ef028c4bac9bc94c92d3af9f38@AcuMS.aculab.com> (raw)
In-Reply-To: <20231206224359.GR1674809@ZenIV>
From: Al Viro
> Sent: 06 December 2023 22:44
>
> On Wed, Dec 06, 2023 at 11:10:45AM +0000, David Laight wrote:
>
> > Do we?
> > I've not seen any justification for this at all.
> > IIRC the ICMPv4 reply code needs the checksum function return 0xffff
> > for all-zero input.
> >
> > So the correct and simple fix is to initialise the sum to 0xffff
> > in the checksum function.
>
> You do realize that ICMPv4 reply code is not the only user of those,
> right? Sure, we can special-case it there. And audit the entire
> call tree, proving that no other call chains need the same.
>
> Care to post the analysis? I have the beginnings of that and it's already
> long and convoluted and touches far too many places, all of which will
> have to be watched indefinitely, so that changes in there don't introduce
> new breakage.
>
> I could be wrong. About many things, including the depth of your
> aversion to RTFS. But frankly, until that analysis shows up somewhere,
> I'm going to ignore your usual handwaving.
This code is calculating the ip-checksum of a buffer.
The is subtly different from the 16bit 1's complement sum of
the buffer.
Now 0x0000 and 0xffff are mathematically equivalent but various specs
to treat them differently.
Consider the UDP header checksum.
For IPv4 the checksum field can be zero - but that means 'not
calculated' and should be treated as a valid checksum.
But IPv6 treats zero as an error.
If the 1's complement sum is 0xffff then the checksum field
need to contain 0xffff not 0.
This means you really need to calculate 1 + ~sum16(1, buff, len)
(ie initialise the sum to 1 rather than 0 or 0xffff.)
The issue that showed this was zero being put into an ICMP message
when all the bytes were zero instead of the required 0xffff.
The reporter had changed the initialiser and got the required 0xffff
and everything then worked.
That wasn't the copy+checksum path either - since the packet got
sent rather than EFAULT being generated.
If I read the code/specs I'll only find places where the buffer
is guaranteed to be non-zero (pretty much all of IP, TCP and UDP)
or 0xffff is the required valued (ICMP).
Since you are proposing this patch I think you need to show
a concrete example of where an all zero buffer is required to
generate a zero checksum value but a non-zero buffer must
generate 0xffff.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
next prev parent reply other threads:[~2023-12-07 9:59 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-18 6:18 [PATCH] amd64: Fix csum_partial_copy_generic() gus Gusenleitner Klaus
2023-10-18 7:36 ` Eric Dumazet
2023-10-18 15:12 ` Thomas Gleixner
2023-10-18 15:42 ` Al Viro
2023-10-18 17:37 ` Thomas Gleixner
2023-10-19 4:44 ` AW: " gus Gusenleitner Klaus
2023-10-19 5:02 ` Al Viro
2023-10-19 6:14 ` Al Viro
2023-10-19 6:39 ` Al Viro
2023-10-19 7:39 ` Eric Dumazet
2023-10-19 8:06 ` Al Viro
2023-10-20 8:32 ` Vincent Whitchurch
2023-10-20 20:27 ` David Laight
2023-10-21 7:15 ` Al Viro
2023-10-21 22:22 ` Al Viro
2023-10-22 11:03 ` David Laight
2023-10-22 11:11 ` Al Viro
2023-10-23 8:16 ` David Laight
2023-10-24 2:59 ` Al Viro
2023-10-22 19:40 ` [RFC][PATCH] fix csum_and_copy_..._user() idiocy. " Al Viro
2023-10-22 19:46 ` Al Viro
2023-10-23 10:37 ` Thomas Gleixner
2023-10-24 4:26 ` Al Viro
2023-10-24 12:31 ` Thomas Gleixner
2023-10-23 14:44 ` David Laight
2023-10-24 3:53 ` Al Viro
2023-12-05 2:21 ` [RFC][PATCHES v2] checksum stuff Al Viro
2023-12-05 2:23 ` [PATCH v2 01/18] make net/checksum.h self-contained Al Viro
2023-12-05 2:23 ` [PATCH v2 1/9] reiserfs: Avoid touching renamed directory if parent does not change Al Viro
2023-12-05 2:23 ` [PATCH v2 02/18] get rid of asm/checksum.h includes outside of include/net/checksum.h and arch Al Viro
2023-12-05 2:23 ` [PATCH v2 2/9] ocfs2: Avoid touching renamed directory if parent does not change Al Viro
2023-12-05 2:23 ` [PATCH v2 03/18] make net/checksum.h the sole user of asm/checksum.h Al Viro
2023-12-05 2:23 ` [PATCH v2 3/9] udf_rename(): only access the child content on cross-directory rename Al Viro
2023-12-05 2:23 ` [PATCH v2 4/9] ext2: Avoid reading renamed directory if parent does not change Al Viro
2023-12-05 2:23 ` [PATCH v2 04/18] Fix the csum_and_copy_..._user() idiocy Al Viro
2023-12-05 2:24 ` [PATCH v2 05/18] bits missing from csum_and_copy_{from,to}_user() unexporting Al Viro
2023-12-05 2:24 ` [PATCH v2 5/9] ext4: don't access the source subdirectory content on same-directory rename Al Viro
2023-12-05 2:24 ` [PATCH v2 06/18] consolidate csum_tcpudp_magic(), take default variant into net/checksum.h Al Viro
2023-12-05 2:24 ` [PATCH v2 6/9] f2fs: Avoid reading renamed directory if parent does not change Al Viro
2023-12-05 2:24 ` [PATCH v2 07/18] consolidate default ip_compute_csum() Al Viro
2023-12-05 2:24 ` [PATCH v2 7/9] rename(): fix the locking of subdirectories Al Viro
2023-12-05 2:24 ` [PATCH v2 08/18] alpha: pull asm-generic/checksum.h Al Viro
2023-12-05 2:24 ` [PATCH v2 8/9] kill lock_two_inodes() Al Viro
2023-12-05 2:24 ` [PATCH v2 09/18] mips: pull include of asm-generic/checksum.h out of #if Al Viro
2023-12-05 2:24 ` [PATCH v2 9/9] rename(): avoid a deadlock in the case of parents having no common ancestor Al Viro
2023-12-05 2:24 ` [PATCH v2 10/18] nios2: pull asm-generic/checksum.h Al Viro
2023-12-05 2:24 ` [PATCH v2 11/18] x86: merge csum_fold() for 32bit and 64bit Al Viro
2023-12-05 2:24 ` [PATCH v2 12/18] x86: merge ip_fast_csum() " Al Viro
2023-12-05 2:24 ` [PATCH v2 13/18] x86: merge csum_tcpudp_nofold() " Al Viro
2023-12-05 2:24 ` [PATCH v2 14/18] amd64: saner handling of odd address in csum_partial() Al Viro
2023-12-05 2:24 ` [PATCH v2 15/18] x86: optimized csum_add() is the same for 32bit and 64bit Al Viro
2023-12-05 2:24 ` [PATCH v2 16/18] x86: lift the extern for csum_partial() into checksum.h Al Viro
2023-12-05 2:24 ` [PATCH v2 17/18] x86_64: move csum_ipv6_magic() from csum-wrappers_64.c to csum-partial_64.c Al Viro
2023-12-05 2:24 ` [PATCH v2 18/18] uml/x86: use normal x86 checksum.h Al Viro
2024-01-03 22:02 ` Richard Weinberger
2023-12-05 2:27 ` [RFC][PATCHES v2] checksum stuff Al Viro
2023-12-06 11:10 ` David Laight
2023-12-06 22:43 ` Al Viro
2023-12-07 9:58 ` David Laight [this message]
2023-12-08 12:04 ` David Laight
2023-12-08 14:17 ` Al Viro
2023-12-08 15:29 ` Al Viro
2023-12-08 15:56 ` David Laight
2023-12-08 18:35 ` Al Viro
2023-10-19 11:45 ` AW: [PATCH] amd64: Fix csum_partial_copy_generic() Thomas Gleixner
2023-10-19 10:33 ` David Laight
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d7faa6ef028c4bac9bc94c92d3af9f38@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=gus@keba.com \
--cc=kuba@kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pabeni@redhat.com \
--cc=tglx@linutronix.de \
--cc=viro@ftp.linux.org.uk \
--cc=viro@zeniv.linux.org.uk \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome