linux-kernel - Re: [PATCH v3 0/4] enable early printing of hashed pointers

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:   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