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: <20180504022349.GH29205@thunk.org>
Date:   Thu, 3 May 2018 22:23:49 -0400
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     "Tobin C. Harding" <me@...in.cc>
Cc:     linux-kernel@...r.kernel.org,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Randy Dunlap <rdunlap@...radead.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Kees Cook <keescook@...omium.org>,
        Anna-Maria Gleixner <anna-maria@...utronix.de>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH v3 0/4] enable early printing of hashed pointers

On Fri, May 04, 2018 at 09:07:37AM +1000, Tobin C. Harding wrote:
> Currently if an attempt is made to print a pointer before there is
> enough entropy then '(____ptrval____)' is printed.  This makes debugging
> stack traces during early boot difficult.
> 
> It was observed that we can relax the requirement for cryptographically
> secure hashing when debugging while still maintaining pointer hashing
> behaviour.  This allows kernels to be debugged without developers
> relying on different pointer printing behavior.
> 
> Using the hw RNG if available solves this problem for those machines
> that have a hardware RNG, we would like to solve it for _all_ machines.
> 
> Patch 1 - Whitespace fixes.
> Patch 2 - Fix get_random_bytes_arch()
> Patch 3 - Use hw RNG for pointer hashing if available (by default).
> Patch 4 - Use insecure hashing with command line option 'debug_early_boot'.

What tree are these patches going in?  It seems to be equally split
between random and core kernel code.  I'm happy taking it in via the
random tree, or if it goes in some other patch (I've already ack'ed
the random changes).  I just want to make sure other folks aren't
assuming I was going take the patches, while I was assuming it would
go to Linus some other way.

				- Ted

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ