RFR: 8227587: Add internal privileged System.loadLibrary

[Claes Redestad]

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