Date: Thu, 26 Jan 2012 12:52:43 -0500 From: David Schultz <das@FreeBSD.ORG> To: Andrey Chernov <ache@FreeBSD.ORG>, John Baldwin <jhb@FreeBSD.ORG>, Mark Murray <markm@FreeBSD.ORG>, src-committers@FreeBSD.ORG, svn-src-all@FreeBSD.ORG, svn-src-head@FreeBSD.ORG Subject: Re: svn commit: r230230 - head/sys/dev/random Message-ID: <20120126175243.GA19199@zim.MIT.EDU> In-Reply-To: <20120126165521.GA92622@vniz.net> References: <E1Rny2A-000C3x-O6@groundzero.grondar.org> <20120126143819.GA88677@vniz.net> <20120126155626.GA92229@vniz.net> <201201261132.38320.jhb@freebsd.org> <20120126165521.GA92622@vniz.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120126175243.GA19199>