RFR: 8227587: Add internal privileged System.loadLibrary

Mandy Chung mandy.chung at oracle.com
Fri Jul 12 18:03:20 UTC 2019


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