[concurrency-interest] ThreadLocalRandom clinit troubles

Stanimir Simeonoff stanimir at riflexo.com
Fri Jun 20 12:16:05 UTC 2014

Hi Peter,
Irrc, ServiceLoader.load(NameServiceDescriptor.class) uses
Thread.contextClassLoader to load the services. Depending how late the
NameServices is getting initialized, perhaps it can be used to circumvent
the loader available at clinit of InetAddress.

I am not sure it could be a real security concern (as the caller has to be
authorized to create custom classloaders), yet the behavior is not exactly
the same. Storing Thread.currentThread().getContextClassLoader() during
clinit in a WeakRefernce (and clearing on use) should be closest to the
original code.


On Fri, Jun 20, 2014 at 2:20 PM, Peter Levart <peter.levart at gmail.com>

> On 06/20/2014 11:10 AM, Peter Levart wrote:
>> Perhaps a more lazy initialization of NetworkInterface class that does
>> not trigger initialization of NS providers could help. We just need to
>> invoke two methods on NetworkInterface:
>> - static NetworkInterface.getNetworkInterfaces()
>> - instance NetworkInterface.getHardwareAddress()
>> both of which could provide the result without the need of NS providers,
>> I think.
>> This would solve the most general case of using TLR. The case that
>> doesn't involve SecureRandom's help which I think is rarely needed and not
>> default.
>> Regards, Peter
> Hi,
> A patch that solves this is a patch to InetAddress. We can't suppress
> initialization of InetAddress as part of NetworkInterface initialization,
> but we can suppress initialization of NameService providers as part of
> InetAddress initialization by moving them into a nested class called
> NameServices:
> http://cr.openjdk.java.net/~plevart/jdk9-dev/InetAddress.
> NameServices/webrev.01/
> This should solve Martin's issue, but the patch to TLR initialization
> could be applied nevertheless, since it might help overcome possible issues
> when using SecureRandom for TLR's seed.
> Regards, Peter
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

More information about the core-libs-dev mailing list