netdev - Re: [PATCH net-next 3/6] random32: add prandom_reseed_late() and call when nonblocking pool becomes initialized

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] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 12 Nov 2013 06:53:50 -0500
From:	Theodore Ts'o <tytso@....edu>
To:	Daniel Borkmann <dborkman@...hat.com>, davem@...emloft.net,
	shemminger@...workplumber.org, fweimer@...hat.com,
	netdev@...r.kernel.org, Eric Dumazet <eric.dumazet@...il.com>,
	linux-wireless@...r.kernel.org
Subject: Re: [PATCH net-next 3/6] random32: add prandom_reseed_late() and
 call when nonblocking pool becomes initialized

On Tue, Nov 12, 2013 at 01:03:07AM +0100, Hannes Frederic Sowa wrote:
>
> We are much too early to enumerate hardware, so it would be hard to
> integrate something like mac addresses etc.

Stupid question --- is there a reason why the minstrel code is
initialized so early when it is compiled into the kernel?  Can we
change it so it gets initialized later, after the devices are
initialized and we get the mac addresses?  

> Btw. do you see problems regarding get_random_int on architectures without
> hardware offloading?
> 
> We are initializing random_int_secret really late (after all the init
> calls) and I wonder if we should also use a two stage initialization
> there, so we have a more unpredictable MD5 hash at early boot.

Most of the users of get_random_int(), at least to date, have been for
things like ASLR.  A quick audit shows only one device driver user
that might be impacted: drivers/net/wireless/cw1200/wsm.c.

It's not a bad idea to do a two stage init just in case
get_random_int() gets used by other code --- although that brings up
something that I know is really needed, but which I haven't had time
to try to address yet: we really need to document all of the various
interfaces that various kernel routines can use to get random numbers,
and document what their performance and security characteristics are.
We have probably have a lot of code where the authors didn't realize
that some other interface would be a better match for their needs, or
the code is old enough that predates some of the newer interfaces.

    	    	       	    	     - Ted
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html