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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 4 May 2018 13:50:29 +1000
From:   "Tobin C. Harding" <me@...in.cc>
To:     "Theodore Y. Ts'o" <tytso@....edu>, 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 Thu, May 03, 2018 at 10:23:49PM -0400, Theodore Y. Ts'o wrote:
> 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.

Thanks for verifying this Ted, I was wondering the same thing.  Perhaps
this set should be split up, patch 4 is not related to the first three.
Assuming no comments come in over the next few days it looks like people
are ok with the first 3 patches, perhaps you could take those through
your tree (I can resend separately if easier for you).  I could then
re-spin the final patch a few more times and perhaps Andrew would take
it through his tree?

Feel free to violently correct me, I'm still learning the ins-and-outs
of the patch pathway to Linus.

thanks,
Tobin.