Re: [PATCH 3/3] vsprintf: Add use-early-random-bytes cmd line option

[tcharding <me@tobin.cc>]

On Tue, May 01, 2018 at 09:45:07PM -0400, Steven Rostedt wrote:
> On Wed, 2 May 2018 11:27:58 +1000
> tcharding <me@tobin.cc> wrote:
> 
> > On Wed, May 02, 2018 at 01:02:34AM +0000, Linus Torvalds wrote:
> > > On Tue, May 1, 2018 at 4:34 PM Tobin C. Harding <me@tobin.cc> wrote:
> > > 
> > >   
> > > > This option should NOT be enabled on production kernels.  
> > > 
> > > I think with your fixes to get_random_bytes_arch(), it's perfectly fine to
> > > use on production kernels (and doesn't even need a kernel command line
> > > option).
> > > 
> > > It was only with the "use weak crypto" (that get_random_bytes_arch() used
> > > to fall back on) that it was a problem. That fixed "verify that
> > > get_random_bytes_arch() really uses hw crypto" is certainly not weak crypto.  
> 
> Except for where hardware vendors control what random bytes you
> actually get ;-)
> 
> > 
> > Ok, I'll wait to see if anyone with a more paranoid disposition adds to
> > this otherwise will implement as suggested.
> 
> I still test on a lot of old boxes (my old workstations turn into my
> test boxes). I haven't tried to see which machines have RDRAND support.
> But regardless, can we still have a command line option that forces
> early randomization even if RDRAND isn't supported?

This is now two different issues, right?

1) get_random_bytes_arch() was broken for this use case - this set fixes
   that.  We can just use the hw RNG if available for key material to
   hash pointers with.

2) Early stage debugging is still an issue on boxes without RDRAND.  If
   we are agreed that we don't need cryptographically secure hashing on
   test kernels then we could just use a simple hashing algorithm, for
   example multiply the address by a prime and take the high 32 bits (as
   long as it was guarded by a command line option).

thanks,
Tobin.