JEP Improve Security Manager Performance
Peter Firmstone
peter.firmstone at zeus.net.au
Fri Jul 11 04:48:53 UTC 2014
Sean,
Would a SecurityManager and Policy provider combination that has no
perceptable impact on performance and is highly scalable qualify?
It's a drop in fully compatible replacement.
Regards,
Peter.
-------- Original Message --------
Subject: Re: Concurrent Policy provider
Date: Thu, 10 Jul 2014 22:20:33 -0500
From: David M. Lloyd <david.lloyd at redhat.com>
To: security-dev at openjdk.java.net
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