News for hackers. Stuff that matters.
Re:Fixing Getrandom() by tudelo on Tuesday October 01, 2019 @02:59PM (#21129269)
I used to work on a Java application that used a bunch of libraries, and specifically I remember one of the libraries generated some identifier using urandom. I think it was axis2 or something like that. There was unexplainably random hangs when trying to read from urandom. The wikipedia article says that urandom should not block. Anyone smarter than me that can understand this article have any reason why urandom hangs?
Re:Fixing Getrandom() by dwaite on Wednesday October 02, 2019 @12:29AM (#21133437)
Java on Linux at used to have this bad behavior where it would short-circuit configuration to use /dev/urandom to use its own internal RNG based on /dev/random. It did not create a single global seed for the internal random number generator, so some systems could overwhelm the entropy pool.

I've solved this for some systems by changing the java security properties file to instead point to /dev/./urandom .

Re:Fixing Getrandom() by tudelo on Friday October 04, 2019 @11:28AM (#21158599)
I did that and even then it still happened :( one of lifes great mysteries
Re:Fixing Getrandom() by fragmede on Tuesday October 01, 2019 @03:36PM (#21129651)
Impossible to say without a deeper inspection of the system, but given `/dev/random` does block, the answer is something is redirecting urandom to random. On the system, does cat urandom ever block? Step one is the reproduce it outside of Java and if that's not possible, start digging into the Java library's code. If it is, then start digging into `glibc`, devfs, the kernel.

Something in the chain switched urandom and random. Isolate each component until the culprit is found.

Re:Fixing Getrandom() by hinkley on Tuesday October 01, 2019 @03:52PM (#21129816)
Java app servers with high request rates suffered this problem, leading to throttling of SSL session creation and thus reducing effective requests per second on the server.

I doubled throughput on two different projects by 'fixing' the /dev/random-/dev/urandom problem.

But writing your own can be worse. Stumbled onto a substantial CSRNG bug on an embedded system than was ignoring most of the seed data due to a premature optimization in the ingestion code. Even after that the people who wrote the glue code wanted to do their own entropy mixing. Lesson not learned, at all.

Re:Fixing Getrandom() by saagarjha on Tuesday October 01, 2019 @03:08PM (#21129349)
After boot, and once it's been initialized with sufficient entropy, the /dev/urandom PRNG should not block. Can you provide more detail as to what it was doing?