ThreadLocalRandom clinit troubles (original) (raw)

Peter Levart peter.levart at gmail.com
Thu Jun 19 07:49:43 UTC 2014

Hi Martin,

What version of TLR are you looking at? As far as I remmember, the InetAddress-related code to obtain initial seed has been replaced by NetworkInterface.getHardwareAddress(). Is this still triggering the initialization of InetAddress or is this the case of using "java.util.secureRandomSeed" set to "true" ? Can you show the whole stack trace?

On 06/19/2014 06:25 AM, Martin Buchholz wrote:

ThreadLocalRandom's clinit method creates an intermediate broken state of ThreadLocalRandom and then proceeds to run some networking code to get some more machine-specific entropy in initialSeed(). This will fail if the networking code ever recursively uses a (not yet functional) ThreadLocalRandom. The clinit for InetAddress can cause arbitrary code to be run,

at

java.util.ServiceLoader$LazyIterator.hasNextService(ServiceLoader.java:354)

at java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:393) at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:474) at java.net.InetAddress$3.run(InetAddress.java:923) at java.net.InetAddress$3.run(InetAddress.java:918) at java.security.AccessController.doPrivileged(Native Method) at java.net.InetAddress.createNSProvider(InetAddress.java:917) at java.net.InetAddress.(InetAddress.java:962)

if the sun.net.spi.nameservice.provider system property is defined.

The current strategy of ThreadLocalRandom relying on other java code for initialization seems risky. Safer would be to have native code provide some entropy at program startup for use by ThreadLocalRandom. I don't have a clean solution for this problem (other than to rip out initialSeed()). Strictly more reliable would be to mix in the entropy from the system at the end of ThreadLocalRandom's clinit instead of the beginning, but the basic problem remains.

Would it be acceptable for TLR to be functional even when invoked during it's clinit, but using a less randomized "seeder" (based only on current time) and after the "networking" or SecureRandom code is finished, complete the initialization of "seeder" state and clear the thread-local probe so that TLR's thread state is re-initialized afterwards. for example:

http://cr.openjdk.java.net/~plevart/jdk9-dev/TLR.seeder/webrev.01/

Regards, Peter

More information about the core-libs-dev mailing list