A more important question would be "Why does asynchronous DNS resolution require random data in the first place?"
Linux /dev/urandom and concurrency
11–20 of 80 posts
Re: Linux /dev/urandom and concurrency
#12Earlier quoted context omitted.
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…
I guess that means all go applications that use crypto/rand are considered misdesigned then[1].
Re: Linux /dev/urandom and concurrency
#13Earlier quoted context omitted.
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…
So, would a possible solution be to check how many people are using the random generator at once? If only one process is currently accessing /dev/urandom, then avoid the spinlock and problem solved. Or, I am completely wrong.
Re: Linux /dev/urandom and concurrency
#14overreliance 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
/dev/urandom is not /dev/random.
Re: Linux /dev/urandom and concurrency
#15A more important question would be "Why does asynchronous DNS resolution require random data in the first place?"
So you can randomise the ID in the request packet to help protect against cache poisoning. And also so you can apply 0x20 bit (x) encoding to the qname for further protection.
(x) http://courses.isi.jhu.edu/netsec/papers/increased_dns_resis...
Re: Linux /dev/urandom and concurrency
#16A more important question would be "Why does asynchronous DNS resolution require random data in the first place?"
IDs of requests?
Re: Linux /dev/urandom and concurrency
#17Earlier quoted context omitted.
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…
I guess that means all go applications that use crypto/rand are considered misdesigned then[1]. [1]: http://golang.org/src/pkg/crypto/rand/rand_unix.go#L30
If you're using crypto/rand to yank a whole bunch of random numbers out for the purpose of deciding which DNS record to use when multiple DNS records were returned, yes, the Go application is misdesigned. Such applications should be using math/rand. Seeding your math/rand from crypto/rand isn't a bad idea, but you don't need to be hammering on /dev/urandom in such code.
Re: Linux /dev/urandom and concurrency
#18Seed a secure userspace PRNG from urandom, perhaps?
Re: Linux /dev/urandom and concurrency
#19A more important question would be "Why does asynchronous DNS resolution require random data in the first place?"
So you can randomise the ID in the request packet to help protect against cache poisoning. And also so you can apply 0x20 bit (x) encoding to the qname for further protection. (x) http://courses.isi.jhu.edu/netsec/papers/increased_dns_resis...
Hard to say w/o seeing the data in question, but based on that, perhaps nscd or re-using curl handles could mitigate their frustration w/ runtime.
Re: Linux /dev/urandom and concurrency
#20Earlier quoted context omitted.
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…
So, would a possible solution be to check how many people are using the random generator at once? If only one process is currently accessing /dev/urandom, then avoid the spinlock and problem solved. Or, I am completely wrong.
If there is only one process, then no spinlock contention, so no problem.
The problem comes with multiple processes competing for the lock.