Concurrent Policy provider

David M. Lloyd david.lloyd at redhat.com
Fri Jul 11 03:20:33 UTC 2014 

Maybe you already know this, but this past April, Sean Mullan (from 
Oracle) posted a "JEP Review Request" [1] for a blanket initiative to 
improve security manager performance.

This kind of thing sounds like exactly the sort of thing that would fit 
in under that initiative, IMO.

[1] 
http://mail.openjdk.java.net/pipermail/security-dev/2014-April/010432.html

On 07/10/2014 10:00 PM, Peter Firmstone wrote:
> Would there be interest in using a Policy provider and SecurityManager
> designed for concurrency in Java 9?
>
> Some of the issues experienced and solutions are mentioned below.
>
> http://svn.apache.org/viewvc/river/jtsk/skunk/qa_refactor/trunk/src/org/apache/river/api/security/
>
>
> Regards,
>
> Peter.
>
> -------- Original Message --------
> Subject:     Concurrency-interest Digest, Vol 113, Issue 45
> Date:     Mon, 30 Jun 2014 12:00:01 -0400
> From:     concurrency-interest-request at cs.oswego.edu
> Reply-To:     concurrency-interest at cs.oswego.edu
> To:     concurrency-interest at cs.oswego.edu
>
>
>
> Send Concurrency-interest mailing list submissions to
>      concurrency-interest at cs.oswego.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
>      http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> or, via email, send a message with subject or body 'help' to
>      concurrency-interest-request at cs.oswego.edu
>
> You can reach the person managing the list at
>      concurrency-interest-owner at cs.oswego.edu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Concurrency-interest digest..."
>
>
> Today's Topics:
>
>     1. Re: ThreadLocalRandom clinit troubles (Peter Firmstone)
>     2. Re: ThreadLocalRandom clinit troubles (Alan Bateman)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 30 Jun 2014 20:02:30 +1000
> From: Peter Firmstone<peter.firmstone at zeus.net.au>
> To: Peter Levart<peter.levart at gmail.com>
> Cc: concurrency-interest at cs.oswego.edu
> Subject: Re: [concurrency-interest] ThreadLocalRandom clinit troubles
> Message-ID:<53B135B6.1030105 at zeus.net.au>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Hi Peter,
>
> There are a number of bottlenecks throughout the security
> infrastructure, we have reimplemented it as follows to avoid them and
> have also addressed some long standing issues:
>
> SecurityManager - cache previously checked AccessControlContext's
> (using a cache structure based on Cliff Click's non blocking hash map
> and Doug Lee's concurrent skip list set), to avoid repeately calling the
> policy provider (for example, you have numerous tasks in an
> ExecutorService and each has an identical AccessControlContext and all
> tasks cause a SocketPermission check).
>
> Policy provider - replaced the built in Java policy provider.  The built
> in Java Policy provider will hold a lock while making DNS calls,
> bringing all permission checks to a grinding halt.  It will also hold
> locks while accessing the file system.
>
> To avoid making DNS calls we've implemented our own policy provider,
> originated from Apache Harmony, but modified to use non blocking
> immutability.  It creates PermissionCollection's on demand, they're not
> shared among threads and are ordered in the most favourable order for a
> fast result.  It also supports undocumented Java file policy provider
> functionality.  Because Permission objects are immutable but lazily
> initialized, we call getActions() to ensure their state is completely
> initialized prior to publication.
>
> The policy provider uses a strictly RFC 3986 compliant immutable URI
> class, it performs bit shift operations on ASCII strings during
> normalisation and is used by the policy provider to avoid making DNS
> calls when checking CodeBase policy file permissions.
>
> As a result, the cost of the security infrastructure is less than 1% of
> CPU load during stress tests.
>
> This is part of the Apache River project, JERI (Jini Extensible Remote
> Invocation) performs remote method invocations as tasks running in a
> system threadpool, each task executes concurrently on any exported service.
>
> SecureClassLoader uses CodeSource's as keys in a Map, CodeSource uses
> URL in equals() and hashCode(), so we also have a RFC3986 compliant
> URLClassLoader to avoid making unnecessary DNS calls in SecureClassLoader.
>
> Rather than rely on an external untrusted DNS to determine the identity
> of CodeSource's, we use RFC 3986 compliant normalisation, without making
> DNS calls.  URL's still make DNS calls when retrieving a URL.  The
> difference is, two different host names that previously resolved to an
> identical IP address will no longer be equal, but now we can use dynamic
> dns addresses and fail over replication for domain names that use a
> range of IP addresses to answer for one domain address.  Standard Java
> SecureClassLoader behaviour can be had by setting a system property
>
> This also reduces or avoids calls to the built in java NameServiceProvider.
>
> If this code was in the JVM libraries, we wouldn't need it in our project.
>
> This code is freely available.
>
> Regards,
>
> Peter.
>
> On 29/06/2014 7:29 PM, Peter Levart wrote:
>>
>>  On 06/29/2014 03:53 AM, Peter Firmstone wrote:
>>>
>>>  It does look like a good solution.
>>>
>>>  You might wonder why we still need a custom SecurityManager?
>>>
>>>  Concurrency.
>>>
>>>  The ageing java security infrastructure is a huge bottleneck for
>>>  multithreaded code.
>>>
>>>  Regards,
>>>
>>>  Peter.
>>>
>>
>>  Hi Peter,
>>
>>  If you could identify the most critical bottleneck(s) of default
>>  SecurityManager, there might be a way to fix them...
>>
>>  Regards, Peter
>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>  >  Message: 1
>>>  >  Date: Thu, 26 Jun 2014 19:10:22 -0400
>>>  >  From: Doug Lea<dl at cs.oswego.edu<mailto:dl at cs.oswego.edu>>
>>>  >  To: Peter Levart<peter.levart at gmail.com
>>>  <mailto:peter.levart at gmail.com>>
>>>  >  Cc: core-libs-dev<core-libs-dev at openjdk.java.net
>>>  <mailto:core-libs-dev at openjdk.java.net>>,    OpenJDK
>>>  >  <security-dev at openjdk.java.net
>>>  <mailto:security-dev at openjdk.java.net>>,    concurrency-interest
>>>  >  <concurrency-interest at cs.oswego.edu
>>>  <mailto:concurrency-interest at cs.oswego.edu>>
>>>  >  Subject: Re: [concurrency-interest] ThreadLocalRandom clinit
>>> troubles
>>>  >  Message-ID:<53ACA85E.2030407 at cs.oswego.edu
>>>  <mailto:53ACA85E.2030407 at cs.oswego.edu>>
>>>  >  Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>>  >
>>>  >
>>>  >  Peter: Thanks very much for attacking the shocking impact/complexity
>>>  >  of getting a few seed bits.
>>>  >
>>>  >  On 06/25/2014 01:41 PM, Peter Levart wrote:
>>>  >  >
>>>  >  >  Peeking around in the sun.security.provider package, I found
>>> there
>>>  >  >  already is a minimal internal infrastructure for obtaining random
>>>  >  >  seed. It's encapsulated in package-private abstract class
>>>  >  >  sun.security.provider.SeedGenerator with 4 implementations. It
>>> turns
>>>  >  >  out that, besides Java-only fall-back implementation called
>>>  >  >  ThreadedSeedGenerator and generic URLSeedGenerator, there are
>>>  also two
>>>  >  >  implementations of NativeSeedGenerator (one for UNIX-es which is
>>>  just
>>>  >  >  an extension of URLSeedGenerator and the other for Windows which
>>>  uses
>>>  >  >  MS CryptoAPI). I made a few tweaks that allow this
>>>  sub-infrastructure
>>>  >  >  to be used directly in ThreadLocalRandom and SplittableRandom:
>>>  >  >
>>>  >  >
>>>  http://cr.openjdk.java.net/~plevart/jdk9-dev/TLR_SR_SeedGenerator/webrev.01/
>>>
>>>  <http://cr.openjdk.java.net/%7Eplevart/jdk9-dev/TLR_SR_SeedGenerator/webrev.01/>
>>>
>>>
>>>  >  >
>>>  >
>>>  >  This seems to be the best idea yet, assuming that people are OK
>>>  >  with the changes to sun.security.provider.SeedGenerator and
>>>  >  NativeSeedGenerator.java
>>>  >
>>>  >  -Doug
>>>
>>>
>>>
>>>  _______________________________________________
>>>  Concurrency-interest mailing list
>>>  Concurrency-interest at cs.oswego.edu
>>>  http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 30 Jun 2014 13:53:38 +0100
> From: Alan Bateman<Alan.Bateman at oracle.com>
> To: Peter Firmstone<peter.firmstone at zeus.net.au>
> Cc: concurrency-interest at cs.oswego.edu
> Subject: Re: [concurrency-interest] ThreadLocalRandom clinit troubles
> Message-ID:<53B15DD2.8020200 at oracle.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 30/06/2014 11:02, Peter Firmstone wrote:
>>  Hi Peter,
>>
>>  There are a number of bottlenecks throughout the security
>>  infrastructure, we have reimplemented it as follows to avoid them and
>>  have also addressed some long standing issues:
>>
>>
>>  If this code was in the JVM libraries, we wouldn't need it in our
>>  project.
>>
> Have you considered bring some of these patches to OpenJDK?
>
> On RFC 3986 (you mentioned this a number of times) then there were
> previous attempts bring URI up to this, unfortunately had to be backed
> out due to compatibility issues and other breakage. It's definitely
> something that needs to be looked at again.
>
> -Alan
>
>
>
> ------------------------------
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
> End of Concurrency-interest Digest, Vol 113, Issue 45
> *****************************************************
>

-- 
- DML

More information about the security-dev mailing list