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

[Anil Saldhana]

On 03/04/2013 09:03 AM, David M. Lloyd wrote:
> 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.
The reason why we had package level securityactions/privileged blocks
was mainly to provision the permissions down to the package level (if
need be). Having singleton classes representing priv blocks may be ok
for AS core code. However, how do we prevent applications from using these
singleton priv blocks?

>
> 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