[concurrency-interest] ThreadLocalRandom clinit troubles (original) (raw)
Stanimir Simeonoff stanimir at riflexo.com
Fri Jun 20 12:16:05 UTC 2014
- Previous message: ThreadLocalRandom clinit troubles
- Next message: [concurrency-interest] ThreadLocalRandom clinit troubles
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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.
Cheers, Stanimir
On Fri, Jun 20, 2014 at 2:20 PM, Peter Levart <peter.levart at gmail.com> wrote:
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
- Previous message: ThreadLocalRandom clinit troubles
- Next message: [concurrency-interest] ThreadLocalRandom clinit troubles
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]