Messages in this thread | | | Date | Fri, 10 Dec 2004 10:28:04 -0800 | From | Matt Mackall <> | Subject | Re: Concurrent access to /dev/urandom |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |