svn commit: r230230 - head/sys/dev/random

David Schultz das at FreeBSD.ORG
Thu Jan 26 17:52:44 UTC 2012


On Thu, Jan 26, 2012, Andrey Chernov wrote:
> On Thu, Jan 26, 2012 at 11:32:38AM -0500, John Baldwin wrote:
> > On Thursday, January 26, 2012 10:56:27 am Andrey Chernov wrote:
> > > > On Thu, Jan 26, 2012 at 08:39:07AM -0500, John Baldwin wrote:
> > > > > 		atomic_cmpset_int(&iniseed_state, ARC4_ENTER_NONE, 
> > ARC4_ENTER_HAVE);
> > > > > 		break;
> > > 
> > > Updated version (I hope, final):
> > > 
> > > --- sys/libkern.h.old	2012-01-16 07:15:12.000000000 +0400
> > > +++ sys/libkern.h	2012-01-26 19:38:06.000000000 +0400
> > > @@ -72,6 +72,8 @@ static __inline quad_t qabs(quad_t a) { 
> > >  
> > >  /* Prototypes for non-quad routines. */
> > >  struct malloc_type;
> > > +enum 	arc4_is { ARC4_ENTR_NONE, ARC4_ENTR_HAVE, ARC4_ENTR_DONE };
> > > +extern volatile enum arc4_is arc4rand_iniseed_state;
> > 
> > Atomics don't operate on enums.  You'll need to make it an int and just use 
> > #define's for the 3 states.
> 
> Although current version with current kernel flags works, I forget it is 
> implementation defined in general and not always equal to sizeof(int), 
> f.e. with gcc --short-enums. I'll remade it with #defines, thanx again.

Why complicate things with atomics at all?  A race might result in
arc4random(9) being seeded multiple times, but that's harmless.

The race that worries me is that consumers that call arc4random()
before it is properly seeded will get predictable numbers.  To fix
that robustly, we'd either have to move arc4random() into the
random module (tricky given all the places where it's used), or
make the random module a mandatory part of the kernel.

OpenSSL addresses the issue by providing two APIs: RAND_bytes()
requires a good entropy source and produces cryptographically
strong pseudorandomness.  RAND_pseudo_bytes() produces "good"
(but not necessarily unpredictable) randomness, even in the
absence of an entropy source.  Applications call one interface
or the other, depending on whether they require cryptographic-
quality randomness.


More information about the svn-src-head mailing list