[concurrency-interest] ThreadLocalRandom clinit troubles
peter.levart at gmail.com
Thu Jun 19 08:02:44 UTC 2014
On 06/19/2014 08:32 AM, Stanimir Simeonoff wrote:
> I wonder why just don't use the /dev/random if available on *nix -
> implemented by sun.security.provider.NativePRNG or
> sun.security.mscapi.PRNG() on Windows that calls CryptGenRandom.
> Both support SecureRandomSpi.engineGenerateSeed(int) that provides an
> arbitrary amount of entropy.
> Although the approach would cause some more classes to load, no arbitrary
> providers should be initialized.
I think this is waht you get when you set "java.util.secureRandomSeed"
system property to "true". TLR uses
java.security.SecureRandom.getSeed(8) in this case.
> On Thu, Jun 19, 2014 at 7:25 AM, Martin Buchholz <martinrb at google.com>
>> 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.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.
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
More information about the core-libs-dev