Linux /dev/urandom and concurrency
drsnyder.us
Linux /dev/urandom and concurrency
1–10 of 80 posts
Re: Linux /dev/urandom and concurrency
#2overreliance on /dev/urandom in the presence of little entropy is a well known performance problem on servers. that's why http://en.wikipedia.org/wiki/Hardware_random_number_generato... exist
Re: Linux /dev/urandom and concurrency
#3overreliance on /dev/urandom in the presence of little entropy is a well known performance problem on servers. that's why http://en.wikipedia.org/wiki/Hardware_random_number_generato... exist
A hardware RNG isn't going to do anything to address the scalability problems inherent in having a single shared lock around /dev/urandom.
Re: Linux /dev/urandom and concurrency
#4overreliance on /dev/urandom in the presence of little entropy is a well known performance problem on servers. that's why http://en.wikipedia.org/wiki/Hardware_random_number_generato... exist
If I understand that problem correctly, it has nothing to do with the amount of entropy available but is a simple synchronisation/locking issue. Were reads from, say, /dev/zero ‘protected’ by spinlocks in the same way, the same issue would arise. Conversely, I don’t see how adding a hardware RNG to the system could alleviate the locking issue.
Re: Linux /dev/urandom and concurrency
#5overreliance on /dev/urandom in the presence of little entropy is a well known performance problem on servers. that's why http://en.wikipedia.org/wiki/Hardware_random_number_generato... exist
[deleted]
Re: Linux /dev/urandom and concurrency
#6So why is there a lock for reads from urandom? I suppose if there weren't a lock concurrent reads would all get the same random values?
Re: Linux /dev/urandom and concurrency
#7So why is there a lock for reads from urandom? I suppose if there weren't a lock concurrent reads would all get the same random values?
Good question. The only reference to it that I could find was here http://lkml.iu.edu//hypermail/linux/kernel/0412.1/0181.html but he doesn't explain why it's necessary.
Re: Linux /dev/urandom and concurrency
#8Why does he need so much pseudorandomness. And why use /dev/urandom directly. Maybe using the random library from the programming environment would make more sense.
Re: Linux /dev/urandom and concurrency
#9So why is there a lock for reads from urandom? I suppose if there weren't a lock concurrent reads would all get the same random values?
Yeah basically. That could be a disaster for, say, nonce generation.
The solution would be to have multiple independent entropy pools and either bind them to cores(/sets of cores) or pick a non-busy one in a contention case.
Re: Linux /dev/urandom and concurrency
#10So why is there a lock for reads from urandom? I suppose if there weren't a lock concurrent reads would all get the same random values?
Good question. The only reference to it that I could find was here http://lkml.iu.edu//hypermail/linux/kernel/0412.1/0181.html but he doesn't explain why it's necessary.
From the mail:
>This patch solves a problem where simultaneous reads to /dev/urandom can cause two processes on different processors to get the same value. We're not using a spinlock around the random generation loop because this will be a huge hit to preempt latency. So instead we just use a mutex around random_read and urandom_read. Yeah, it's not as efficient in the case of contention, if an application is calling /dev/urandom a huge amount, it's there's something really misdesigned with it, and we don't want to optimize for stupid applications.