lkml.org 
[lkml]   [2007]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Make rcutorture RNG use temporal entropy
On Mon, Sep 03, 2007 at 08:29:04AM -0500, Matt Mackall wrote:
> On Mon, Aug 27, 2007 at 06:15:54PM -0700, Paul E. McKenney wrote:
> > On Thu, Aug 23, 2007 at 02:40:37PM -0500, Matt Mackall wrote:
> > > Yes. Using a hash function rather than a trivial LFSR is preferable.
> > > But pulling the guts out and giving it an n-bytes interface like
> > > get_random_bytes().
> >
> > OK. But this cannot be the first discussion of getting a fast and loose
> > version of get_random_bytes() into the kernel. Anyplace I should look
> > for cautionary tales? A quick search located a spirited discussion of
> > proposed kernel infrastructure for user-mode random number generation
> > back in 2003, but...
> >
> > Also a 2006 proposal from Stephan Eranian: http://lkml.org/lkml/2006/8/23/41
> > This appears to have gotten zero replies. :-/ (Though not hash-based.)
>
> You probably did the same searches I would do, so no, don't have any
> pointers, just vague recollections.

I was afraid of that. ;-)

> > Other semi-related threads:
> >
> > http://lkml.org/lkml/2005/3/15/102
> > http://lkml.org/lkml/2004/9/23/337
> >
> > Some years back, my reflexive design would have been per-CPU state,
> > accessed with interrupts disabled. Not so good for realtime usage,
> > though. One could go with per-task state in order to avoid the
> > interrupt disabling, which might be OK if the state is quite small.
>
> We only need be concerned here with locking insofar as we'd produce
> duplicate output without it. So it's fairly easy to imagine a lockless
> design using percpu data and perhaps folding in the preemption state.

And if we have a hash on the output, conflicting updates to the state
should be tolerable as well. Still want per-CPU state in order to
avoid cache thrashing, of course, but should be able to avoid preemption
disabling. So the trick will be getting a performance/size/entropy
tradeoff that 75% of the current roll-your-own random-number-generator
uses can live with.

Thanx, Paul
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-09-03 22:11    [from the cache]
©2003-2011 Jasper Spaans