[jboss-as7-dev] About the getSecurityManager() optimization

[David M. Lloyd]

I'm definitely interested in getting some real idea as to the runtime 
cost of (a) these checks and (b) running under a secmgr.  I know for 
sure that (b) is nowhere near as great as I expected (though obviously 
not free), due in part possibly to the Modules<->SM integration code and 
Policy implementation which (I believe) enables certain fast-path 
optimizations within AccessController.

I would also couple that outstanding question with my observation, based 
on analyzing (and refactoring) all 300+ privileged blocks in the AS 
codebase, that none of them are in request fast paths, apart from the 
privileged action interceptors I just wrote (which would only be used to 
replace the (theoretically) similarly expensive existing security 
interceptors).

Overall I'd want to see hard numbers before I worry too much.  As far as 
SPECj goes, if it requires an EE-certified server configuration then it 
may have to run under a security manager no matter what (this 
configuration is required to be supported by EE 7 and might in turn be 
required for apples-to-apples comparison with other servers).  In this 
case it's no longer a question of "do we do this optimization" and more 
a question of "how can we make this as efficient as possible", which IMO 
we should be asking anyway.

Based on the analysis I've done so far, I suspect the greater cost of 
these doPrivileged calls is one-time class init and general GC load, 
both of which I've mitigated really a lot in my security-utils patch 
which removed hundreds of anonymous inner classes and replaced a bunch 
of action objects with a handful of singletons.  And I don't think we're 
at the end of what we can do to improve things on this front either.

On 03/04/2013 08:49 AM, Andrig Miller wrote:
> This concerns me where our SPECjEnterprise2010 benchmarking efforts are concerned.
>
> At this point, we cannot afford anything that could degrade throughput and/or increase CPU utilization.
>
> Andy
>
> ----- Original Message -----
>> From: "David M. Lloyd" <david.lloyd at redhat.com>
>> To: "JBoss AS7 Development" <jboss-as7-dev at lists.jboss.org>
>> Sent: Monday, March 4, 2013 7:36:58 AM
>> Subject: [jboss-as7-dev] About the getSecurityManager() optimization
>>
>> We have, in our core code and frameworks, a few chunks of code like
>> this:
>>
>>     if (getSecurityManager() == null) {
>>        doSomePrivilegedThing();
>>     } else {
>>        AccessController.doPrivileged(new PrivilegedThingAction());
>>     }
>>
>> The idea is that doPrivileged and the action GC load is a cost we
>> should
>> not pay if there's no security manager.
>>
>> There is a potential problem here though.  It is possible to install
>> a
>> security manager after the server is started.  While this may sound
>> like
>> an odd thing to do, we know that at least one third-party library
>> does
>> in fact install a security manager if you don't prevent it from doing
>> so.  Furthermore, as we're required to support running under a
>> security
>> manager, we were talking about allowing the subsystem to install a
>> security manager during extension init instead of requiring it to be
>> sent in to the command at boot.
>>
>> The problem is that if you set a security manager during the window
>> between when the presence of a security manager is checked for, and
>> when
>> the privileged action runs, you run the risk of getting a random
>> SecurityException.  We'll call this problem "the SM race".
>>
>> It seems to me that we have a few options for supporting running
>> under a
>> security manager:
>>
>> 1) Require it to be specified at boot (pass -secmgr to JBoss Modules
>> in
>> the start script)
>> 2) Let it be set by a security manager subsystem
>> 3) Just run with a security manager at all times
>>
>> Only #1 would allow the above optimization to work, and that's only
>> if
>> nobody else sets a security manager in the meantime.
>>
>> Given that fact, coupled with the observation that running under a
>> security manager does not appear to significantly impact server boot
>> time, I'm wondering if we should get rid of this optimization
>> wherever
>> it appears and just always use doPrivileged.
>>
>> Maybe once we see what kind of time impact -secmgr has on the test
>> suite, we'll know whether this is a reasonable course of action (I
>> would
>> expect the performance impact to be somewhere between running with
>> and
>> without a security manager for the non-SM case, and of course no
>> impact
>> for the SM case).
>> --
>> - DML
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>


-- 
- DML