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:   Wed, 6 Dec 2023 22:43:59 +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 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.