linux-kernel - Re: [PATCH 2/2] <linux/hash.h>: Fix hash

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: <CA+55aFyPMrAWqMaA013ZQA0TULtdTXbUh4rgUurMLu40TastuA@mail.gmail.com>
Date:	Mon, 2 May 2016 13:08:03 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	George Spelvin <linux@...izon.com>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Bruce Fields <bfields@...ldses.org>,
	Eric Dumazet <eric.dumazet@...il.com>,
	Jeff Layton <jlayton@...chiereds.net>,
	Linux NFS Mailing List <linux-nfs@...r.kernel.org>,
	Rik van Riel <riel@...hat.com>
Subject: Re: [PATCH 2/2] <linux/hash.h>: Fix hash_64()'s horrible collision problem

On Mon, May 2, 2016 at 3:22 AM, George Spelvin <linux@...izon.com> wrote:
> hash_64() was using a low-bit-weight multiplier, which resulted in
> very bad mixing of the high bits of the input.  In particular,
> page-aligned pointers (low 12 bits not used) were a disaster,

So I did just a minimal for fro 4.6 (and back-porting), which took
just the constants and made _only_ the 64-bit architevture case use
this improved constant for hash_64.

In other words, people who use "hash_long()" or use "hash_64()" on
64-bit architectures will get the improvements, but if you use
hash_64() on a 32-bit architecture you'll conteinue to see the old
behavior.

Quite frankly, looking at some of the explicit hash_64() users, they
seem to be a big dubious anyway. And it won't make things *worse* for
them.

So that simple "just use multiplication unconditionally on 64-bit, and
use the better constant" should fix the actual _practical_ problems
that we've seen. And it shouldn't have any negative consequences,
since as you say, 64-bit architectures universally do have a
multiplier.

The bigger changes will have to be for 4.7 by now, I think.

                     Linus

View attachment "patch.diff" of type "text/plain" (2805 bytes)