Re: Concurrent access to /dev/urandom

[Matt Mackall]

On Fri, Dec 10, 2004 at 11:35:58AM -0500, Theodore Ts'o wrote:
> On Thu, Dec 09, 2004 at 08:47:59PM -0800, Matt Mackall wrote:
> > 
> > But it turns out that we can do this without hashing under the lock
> > after all. What's important is that we mix and extract atomically.
> > Something like this should be quite reasonable:
> 
> The core idea is good, but your patch has a bug in it; it bashes
> add_ptr before it gets saved into r->add_ptr.

I seem to remember having a rationale for that, but I'm fine with your
way.

> Also, it's a more
> complicated than it needed to be (which makes it harder to analyze
> it).

Fair enough. s/__add/mix/, please.

> Finally, it won't work if the pool doesn't get initialized with
> sufficient randomness in the init scripts, and there are too many
> constant zero's in the pool.  But this is easily fixed by using a
> different initialization pattern.

It won't work as in we'll still get duplicates? I don't see how that
happens. The polynomial for the output pools is dense enough that even
on the very next one word mix, we're getting 96 bits changed in the
output and 32 new ones shifted in. And we're always doing at least
three adds for each pull.

It's still suboptimal, perhaps, but I'd rather mix more in
init_std_data. In fact, I was hoping to abolish the pool clearing
function in favor of just init_std_data, as there's not much utility
in going back to a known state here. Let's address this separately.

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/