svn commit: r253786 - in head/sys: dev/random modules/padlock_rng modules/rdrand_rng modules/yarrow_rng

[David O'Brien]

On Tue, Jul 30, 2013 at 01:37:47AM +0400, Andrey Chernov wrote:
> On 30.07.2013 0:58, David E. O'Brien wrote:
> >   Decouple yarrow from random(4) device.
..
> >     We currently have 3 random_adaptors:
> >     + yarrow
> >     + rdrand (ivy.c)
> >     + nehemeiah
> 
> After this commit we again have a problem with badly initialized arc4
> (for rdrand and nehemiah cases, when yarrow isn't loaded), because only
> yarrow have reinit code.

I believe you're talking about this code in
sys/libkern/arc4random.c:arc4rand()

	if (atomic_cmpset_int(&arc4rand_iniseed_state, ARC4_ENTR_HAVE,
	    ARC4_ENTR_SEED) || reseed ||
	   (arc4_numruns > ARC4_RESEED_BYTES) ||
	   (tv.tv_sec > arc4_t_reseed))
		arc4_randomstir();

Without setting 'arc4rand_iniseed_state' from ARC4_ENTR_NONE ->
ARC4_ENTR_HAVE, we would still call arc4_randomstir() periodically due
to (tv.tv_sec > arc4_t_reseed) and (arc4_numruns > ARC4_RESEED_BYTES).

The lacking part is forcing a arc4_randomstir() call the next
arc4rand()/arc4random() call after the PRNG is initialized.
However, I don't think this has a large impact.


But, this situation isn't the big issue.  We have an existing bug where
if one is using a hardware RNG, read_random() never gets changed from
simply being read_random_phony() due to random_modevent() not calling
random_yarrow_init_harvester() thru '(*random_systat->init)()'.  Thus
arc4random() has been weak for thus using the Intel RDRAND or Via
Padlock.

This is something we're going to address, but this commit is an
infrastructure improvement commit (decoupling one thing from another),
not addressing existing bugs or short comings.

thoughts?
-- 
-- David  (obrien at FreeBSD.org)