JDK-8159221 : java.security.SecureRandom.generateSeed freeze when /dev/random is disabled
  • Type: Bug
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 8u77
  • Priority: P4
  • Status: Resolved
  • Resolution: Won't Fix
  • OS: linux
  • CPU: x86_64
  • Submitted: 2016-04-15
  • Updated: 2022-09-28
  • Resolved: 2022-09-28
Related Reports
Duplicate :  
JDK-6521844 - SecureRandom hangs on Linux Systems
Relates :  
JDK-8046113 - JEP 123: Configurable Secure Random-Number Generation
Description
FULL PRODUCT VERSION :
java version "1.8.0_77"
Java(TM) SE Runtime Environment (build 1.8.0_77-b03)
Java HotSpot(TM) 64-Bit Server VM (build 25.77-b03, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
2.6.32-042stab113.21 #1 SMP Wed Mar 23 11:05:25 MSK 2016 x86_64 x86_64 x86_64 GNU/Linux

EXTRA RELEVANT SYSTEM CONFIGURATION :
Its an VPS running under openvz

A DESCRIPTION OF THE PROBLEM :
When I execute the command:

cat /proc/sys/kernel/random/entropy_avail

I'm always getting 0 (zero) as result.

When the java code calls java.security.SecureRandom.generateSeed(int), the code stay blocked (frozen).

Checking with VPS provider, I was notified that /dev/random was disabled.

I believe that JVM should throws an Exception or use a different approach to generate seed

REGRESSION.  Last worked in version 8u77

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Disable /dev/random and call the mentioned method abova.


REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
I have asked to VPS provider enable /dev/random
Comments
Response from submitter: I've shared the details on stackoverflow as you can see here (http://stackoverflow.com/questions/36588242/ssh-daemon-nio2-is-not-starting-anymore ). I remember that on call entropy_avail the result used to be always zero (0). Accordly technical support of host1plus, the dev/random was disable and it was enabled. I have no idea how is possible to do it in VM enviroment (from administrator perspective)
20-10-2016
Sent an email to submitter with the questions asked in above comments.
19-10-2016
Reopening and marking incomplete due to questions asked.
10-06-2016
The SecureRandom API is pretty clear on this point: Note: Depending on the implementation, the generateSeed, reseed and nextBytes methods may block as entropy is being gathered, for example, if the entropy source is /dev/random on various Unix-like operating systems. > I was notified that /dev/random was disabled. What do you mean by disabled? It does not exist, or it exists and can be opened but will never return a value? If the latter, it would be better if you specify a valid entropy source via either System or Security Properties. See the java.security file for more info. As for the other comments, it depends on which SecureRandom impl is being used. If /dev/random does not exist, NativePRNG and SHA1PRNG will fall back to the ThreadedSeedGenerator.
10-06-2016
This issue is similar to JDK-6521844 and JDK-6577564. The latter clearly states that "Users find it confused that sometimes a call to SecureRandom.generateSeed() may hang the system. Since this method needs to gather entropy from a random source, this is inevitable if the source is a special device (say, /dev/random)."
10-06-2016