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.<clinit>(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
