RFR: 8227587: Add internal privileged System.loadLibrary

Peter Levart peter.levart at gmail.com
Wed Jul 17 08:29:12 UTC 2019

Hi Claes,

Am I reading correct that package-private 
ClassLoader.loadLibrary(Class<?> fromClass, String name, boolean 
isAbsolute) wouldn't need to consult SecurityManager wasn't it for 
accessing system properties in private ClassLoader.initializePath(String 
propName). So perhaps if the two calls to initializePath() in the if 
block of ClassLoader.loadLibrary() are wrapped with a single 
doPrivileged(), you wouldn't have to wrap the call to 
JavaLangAccess.loadLibrary in BootLoader. And since initializePath() 
would only be called once and then the results cached, you end up with 
less doPrivileged() wrappings when SecurityManager is present as soon as 
BootLoader.loadLibrary is called the 2nd time.

BTW, there is a data race when accessing usr_paths and sys_paths static 
fields in multi-threaded scenario. Their type is String[] which means 
that the contents of the arrays could be observed uninitialized 
(elements being null) in some thread. Both fields should be made 
volatile (not only sys_paths) as assignment to them can be performed 
more than once in idempotent racy initialization.

Regards, Peter

On 7/16/19 3:48 PM, Claes Redestad wrote:
> Hi,
> refactored to use a BootLoader::loadLibrary API that is only visible
> within the java.base module:
> http://cr.openjdk.java.net/~redestad/8227587/open.03/
> I've retained the bridge to ClassLoader::loadLibrary for performance,
> but without any magic or privilege escalation involved. Moving sys_path
> / systemNativeLibraries out of ClassLoader seems quite complicated, so
> I've not attempted that refactoring for this RFE.
> /Claes
> On 2019-07-12 20:03, Mandy Chung wrote:
>> Just to recap what we discussed offline:
>> We could introduce BootLoader::loadLibrary to load a system native
>> library for boot loader.  sys_path and systemNativeLibraries in
>> ClassLoader implementation are solely for boot loader and it seems
>> cleaner for BootLoader to handle loading of system native libraries
>> where it can be optimized for boot loader.  This would require
>> some refactoring.
>> One possible solution is to add a shared secret to simply call
>> package-private ClassLoader::loadLibrary(Class<?> fromClass, String 
>> name)
>> method and have BootLoader::loadLibrary to check if SM is present
>> and wrap the call with doPriv; otherwise, just call the shared
>> secret loadLibrary method.
>> Then we can investigate in the future to refactor the native library
>> loading implementation to jdk.internal.loader.
>> what do you think?
>> Mandy
>> On 7/12/19 8:25 AM, Mandy Chung wrote:
>>> Claes,
>>> Thanks for exploring this.  I would like to see if we can avoid 
>>> introducing
>>> an internal @CS method (keep @CSM only for public APIs will help 
>>> security
>>> analysis).
>>> There are other alternatives to improve the footprint performance.
>>> One idea is java.base and java.desktop each has its own utility method
>>> to load library.  No change is needed for java.net since only one 
>>> loadLibrary
>>> call.
>>> Another idea is to add BootLoader.loadLibrary that skips the security
>>> permission overhead and only for boot loader use.  It would require
>>> refactoring.
>>> I think java.base and java.desktop having its own utility method is
>>> a simpler solution.
>>> Mandy
>>> On 7/12/19 7:55 AM, Claes Redestad wrote:
>>>> Hi,
>>>> I'm dropping the java.desktop changes, and Mandy has asked me to 
>>>> explore
>>>> options that does not add a new @CallerSensitive entry point, even 
>>>> to a
>>>> strongly encapsulated API like JavaLangAccess
>>>> Easiest of these is to explicitly provide the class context we're
>>>> calling from - with proper assertions. This is marginally more
>>>> performant due avoiding the Reflection.getCallerClass, but slightly 
>>>> less
>>>> convenient.
>>>> http://cr.openjdk.java.net/~redestad/8227587/open.01/
>>>> /Claes
>>>> On 2019-07-12 15:27, Roger Riggs wrote:
>>>>> Hi Claes,
>>>>> Looks fine.
>>>>> Thanks for the updates, Roger
>>>>> On 7/11/19 10:39 AM, Claes Redestad wrote:
>>>>>> Hi Roger,
>>>>>> On 2019-07-11 16:10, Roger Riggs wrote:
>>>>>>> Hi Claes,
>>>>>>> JavaLangAccess.java:
>>>>>>> 316: Add @param tag
>>>>>> done.
>>>>>>> System.java:  2282, 2287
>>>>>>> Runtime.loadLibrary0 makes a second check for a security manager.
>>>>>>> Is there any potential gain by calling ClassLoader.loadLibrary 
>>>>>>> directly?
>>>>>>> None of the internal uses would have a separatorChar.
>>>>>> Most of the gain comes from not having to load one-off PA classes or
>>>>>> lambdas, but of course avoiding the indexOf and a few 
>>>>>> indirections are
>>>>>> marginally helpful to startup. We should at least assert that the
>>>>>> library names are sane, though.
>>>>>>> I expect most of the files need a copyright update.
>>>>>>> The script in <repo>/make/scripts/update_copyright_year.sh 
>>>>>>> should do the work for modified files.
>>>>>> Fixed copyrights and updated in place: 
>>>>>> http://cr.openjdk.java.net/~redestad/8227587/open.00
>>>>>> Thanks!
>>>>>> /Claes

More information about the core-libs-dev mailing list