linux-kernel - Re: [RFC][PATCHES v2] checksum stuff

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]

Date:   Fri, 8 Dec 2023 18:35:09 +0000
From:   Al Viro <viro@...iv.linux.org.uk>
To:     David Laight <David.Laight@...lab.com>
Cc:     "linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
        gus Gusenleitner Klaus <gus@...a.com>,
        Al Viro <viro@....linux.org.uk>,
        Thomas Gleixner <tglx@...utronix.de>,
        lkml <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...hat.com>, "bp@...en8.de" <bp@...en8.de>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        "dsahern@...nel.org" <dsahern@...nel.org>,
        "kuba@...nel.org" <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Eric Dumazet <edumazet@...gle.com>
Subject: Re: [RFC][PATCHES v2] checksum stuff

On Fri, Dec 08, 2023 at 03:56:27PM +0000, David Laight wrote:

> > You add them as natural numbers.  If there is no carry and result
> > fits into N bits, that's it.  If there is carry, you add it to
> > the lower N bits of sum.
> > 
> > Discussion of properties of that operation is present e.g. in
> > RFC1071, titled "Computing the Internet Checksum".
> > 
> > May I politely suggest that some basic understanding of the
> > arithmetics involved might be useful for this discussion?
> 
> Well 0x0000 is +0 and 0xffff is -0, mathematically they are (mostly)
> equal.

As representations of signed integers they are.  However, the origin
of operation in question is irrelevant.  Again, read the fucking RFC.

> I bet that ICMP response (with id == 0 and seq == 0) is the only
> place it is possible to get an ip-checksum of a zero buffer.
> So it will be pretty moot for copy+checksum with can return 0xffff
> (or lots of other values) for an all-zero buffer.

Egads...  Your bets are your business; you *still* have not bothered
to look at the callers of these primitives.  Given the accuracy of
your guesses so far, pardon me for treating any "I bet"/"it stands for
reason"/etc. coming from you as empty handwaving.

> In terms of copy+checksum returning an error, why not reduce the
> 32bit wcsum once (to 17 bits) and return -1 (or ~0u) on error?
> Much simpler than your patch and it won't have the lurking problem
> of the result being assigned to a 32bit variable.

In case you have somehow missed it, quite a few of the affected places
are in assembler.  The same would apply to added code that would do
this reduction.  Which is going to be considerably less trivial than
the changes done in that patch.