[concurrency-interest] ThreadLocalRandom clinit troubles

[Peter Levart]

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.

Regards, Peter

>
> Stanimir
>
>
>
> On Thu, Jun 19, 2014 at 7:25 AM, Martin Buchholz <martinrb at google.com>
> 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.
>>
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest