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:   Mon, 30 Apr 2018 16:57:36 +0000
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Kees Cook <keescook@...omium.org>,
        Anna-Maria Gleixner <anna-maria@...utronix.de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        tcharding <me@...in.cc>
Subject: Re: Hashed pointer issues

On Mon, Apr 30, 2018 at 9:41 AM Steven Rostedt <rostedt@...dmis.org> wrote:

> >
> > And if we really want a command line option, can we make that still hash
> > the pointer, just force the entropy early. That way kernel developers
that
> > test that command line option are still testing the *hashing*, they just
> > are missing the good entropy.

> That may work too. Even with bad entropy, pointers at start up are hard
> to come by, and I can't see a hacker being able to use them as it only
> happens once during boot.

No, if people use the command line option, *all* pointers - not just the
boot-time ones - would get cryptographically bad hashes, since you don't
want to change the hash once it's picked (because then you couldn't use the
hashing to identify objects).

So the boot command line wouldn't affect just the bootup hashing, it would
be bad at runtime too.

But at least a person booting with that option would get the same
*behavior* as everybody else, and they wouldn't be testing something
fundamnetally different (it's still hashing, just not cryptographically
strong).

Although in *practice* we'd have tons of entropy on any modern development
CPU too, since any new hardware will have the hardware random number
generation. Some overly cautious person might not trust it, of course.

                Linus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ