RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied

Doug Simon doug.simon at oracle.com
Mon Jan 30 18:38:35 UTC 2017 

> On 30 Jan 2017, at 17:11, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> Moving it to platform class loader is okay with me.  I’m still unsure if jdk.vm.compiler should be defined by the boot loader instead and you may want to look into in a future release.

We also want jdk.vm.compiler to be upgradeable (as discussed in another thread) so that we can test newer development versions of Graal as the VM JIT via --upgrade-module-path instead of having to rebuild the JDK. As far as I understand, this means it cannot be defined by the boot loader.

> You can change make/common/Modules.gmk to move it to the PLATFORM_MODULES list.

I’ve extended the webrev with that change - please re-review:

http://cr.openjdk.java.net/~dnsimon/8145337_make/webrev

Strangely, there was no existing declaration of jdk.vm.compiler in Modules.gmk.

BTW, I never answered your question:

"How does JVMCI call out to jdk.vm.compiler?  does it load classes using Class::forName with the system class loader?”

It uses JVMCIServiceLocator[1] which is a mechanism built on the standard ServiceLoader.

-Doug

[1] http://hg.openjdk.java.net/jdk9/hs/hotspot/file/2c44cff993b8/src/jdk.vm.ci/share/classes/jdk.vm.ci.services/src/jdk/vm/ci/services/JVMCIServiceLocator.java#l29

> 
>> On Jan 29, 2017, at 12:40 PM, Doug Simon <doug.simon at oracle.com> wrote:
>> 
>> Both jdk.vm.ci and jdk.vm.compiler should be considered part of the VM since they have the same capabilities as Unsafe. Arguably they could be considered even more trusted as they make it easier to do what one could (in theory) do with Unsafe. However, maybe they can still be defined by the platform class loader as 17 of 27 modules in default.policy[1] are granted AllPermission.
>> 
>> -Doug
>> 
>> [1] http://hg.openjdk.java.net/jdk9/dev/jdk/file/tip/src/java.base/share/lib/security/default.policy
>> 
>>> On 28 Jan 2017, at 02:00, Mandy Chung <mandy.chung at oracle.com> wrote:
>>> 
>>> To clarify my question, I am not objecting fo jdk.vm.compiler be included in the runtime. I’m trying to figure what the right loader should be.  It seems to me that it should be defined by the boot loader, as it is part of the VM.  However, another thread suggests that you want jdk.vm.compiler to be upgradeable as Graal version requires other dependencies.  We only support modules defined by the platform class loader be upgradeable.
>>> 
>>> Mandy
>>> 
>>>> On Jan 27, 2017, at 9:52 AM, Mandy Chung <mandy.chung at oracle.com> wrote:
>>>> 
>>>> I have been wondering what defining loader jdk.vm.compiler should be, if used for JIT at runtime.  That’s one reason I mentioned that the VM does not delegate to any of its child loader.
>>>> 
>>>> How does JVMCI call out to jdk.vm.compiler?  does it load classes using Class::forName with the system class loader?
>>>> 
>>>> Mandy
>>>> 
>>>>> On Jan 27, 2017, at 9:23 AM, Doug Simon <doug.simon at oracle.com> wrote:
>>>>> 
>>>>> Since jdk.vm.compiler can be used as the VM compiler, shouldn't it be loaded by the platform class loader? I hope jdk.vm.ci is using the platform class loader. Where is this decision encoded?
>>>>> 
>>>>> Sent from my iPhone
>>>>> 
>>>>>> On Jan 27, 2017, at 5:45 PM, Sean Mullan <sean.mullan at oracle.com> wrote:
>>>>>> 
>>>>>> I would need more time to understand the issue, but default.policy is not the right place to be granting these permissions, since this module is not loaded by the platform class loader. From the first 3 lines of default.policy:
>>>>>> 
>>>>>> //
>>>>>> // Permissions required by modules stored in a run-time image and loaded
>>>>>> // by the platform class loader.
>>>>>> 
>>>>>> --Sean
>>>>>> 
>>>>>>> On 1/26/17 7:36 PM, Mandy Chung wrote:
>>>>>>> I’ll let Drew and Sean to advise on this. (Drew, Sean - sorry for missing to include you in this offlist thread).
>>>>>>> 
>>>>>>> jdk.vm.compiler is defined by the application class loader.  It’d be the first one in JDK if we grant it with AllPermissions and so the security team should be the experts to review this.
>>>>>>> 
>>>>>>> Mandy
>>>>>>> 
>>>>>>>> On Jan 26, 2017, at 1:17 PM, Thomas Wuerthinger <thomas.wuerthinger at oracle.com> wrote:
>>>>>>>> 
>>>>>>>> While the addition of "-Djava.security.policy=jit.policy” is not an issue, we would like to avoid the need for additional files.
>>>>>>>> 
>>>>>>>> To me -XX:+UseJVMCICompiler should pretty much imply that “jdk.vm.compiler” will be granted java.security.AllPermission. The code running in the “jdk.vm.compiler” module can install machine code in the VM. I don’t think there is a scenario in which one would like to run any “untrusted” code as part of this module.
>>>>>>>> 
>>>>>>>> - thomas
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On 26 Jan 2017, at 19:05, Mandy Chung <mandy.chung at oracle.com> wrote:
>>>>>>>>> 
>>>>>>>>> Sicen it’s experimental, when -Djava.security.manager is set, is it an option to require to set -Djava.security.policy as well?
>>>>>>>>> 
>>>>>>>>> java -server -XX:+UnlockExperimentalVMOptions -Djava.security.manager -Djava.security.policy=jit.policy -XX:+BootstrapJVMCI -XX:+UseJVMCICompiler -version
>>>>>>>>> 
>>>>>>>>> $ cat jit.policy
>>>>>>>>> grant codeBase "jrt:/jdk.vm.compiler" {
>>>>>>>>> permission java.security.AllPermission;
>>>>>>>>> };
>>>>>>>>> 
>>>>>>>>> jdk.vm.compiler is defined by the application class loader.  The bootstrap class loader doesn’t delegate to the application class loader when resolving a class that is initiated from a class that is defined by the bootstrap class loader.  I don’t know how VM/JIT interacts with jdk.vm.compiler.   Just to mention it.
>>>>>>>>> 
>>>>>>>>> Mandy
>>>>>>>>> 
>>>>>>>>>> On Jan 26, 2017, at 9:34 AM, Thomas Wuerthinger <thomas.wuerthinger at oracle.com> wrote:
>>>>>>>>>> 
>>>>>>>>>> Mandy,
>>>>>>>>>> 
>>>>>>>>>> We do have an agreement that part of the goal for JVMCI is to be able to run under an experimental flag Graal as a JIT in JDK9 in order for external folks to test Graal as a JIT. Not being able to do so would be considered a blocker for us.
>>>>>>>>>> 
>>>>>>>>>> - thomas
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> On 26 Jan 2017, at 17:57, Mandy Chung <mandy.chung at oracle.com> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> (offlist)
>>>>>>>>>>> 
>>>>>>>>>>> Hi Doug,
>>>>>>>>>>> 
>>>>>>>>>>> I guess this may be coming from security assessment.  As I understand, jdk.vm.compiler is not used for JIT in JDK 9.  Why do you need to ensure jdk.vm.compiler can run with security manager out of the box?
>>>>>>>>>>> 
>>>>>>>>>>> Mandy
>>>>>>>>>>> 
>>>>>>>>>>>> On Jan 26, 2017, at 8:55 AM, Mandy Chung <mandy.chung at oracle.com> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Jan 26, 2017, at 3:13 AM, Doug Simon <doug.simon at oracle.com> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> jdk.vm.compiler is defined by the application class loader and it’s used by AOT tool.  I wonder why it has to run with security manager.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Without java.security.AllPermission, the policy for jdk.vm.compiler required to get through a bootstrap (i.e., java -server -XX:+UnlockExperimentalVMOptions -Djava.security.manager -XX:+BootstrapJVMCI -XX:+UseJVMCICompiler -version) is show below (annotated with comments denoting the methods requiring the permissions):
>>>>>>>>>>>>> 
>>>>>>>>>>>>> :
>>>>>>>>>>>> 
>>>>>>>>>>>> Are -XX:+BootstrapJVMCI -XX:+UseJVMCICompiler supported to use at runtime?
>>>>>>>>>>>> 
>>>>>>>>>>>>> There’s no guarantee that this is all the permissions required since not all code paths are exercised during bootstrap.
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> You can reference JDK tools such as jdk.compiler and jdk.jlink that are not granted with any permission.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Neither of those tools create code and install it in the VM. I don’t think a fine grained SecurityManager policy makes sense for a VM compiler since it could subvert security by compiling/installing malicious code. That is, a VM compiler has to be a trusted component. Keep in mind that user code cannot get to jdk.vm.compiler.
>>>>>>>>>>>> 
>>>>>>>>>>>> My question is not about granting fine-grained permissions vs AllPermissions.  I expect jdk.vm.compiler is used with jdk.aot which does not run with security manager.
>>>>>>>>>>>> 
>>>>>>>>>>>> If jdk.vm.compiler is run with VM as JIT and with security manager, the user can set -Djava.security.policy to a security policy configuring the permission for jdk.vm.compiler.
>>>>>>>>>>>> 
>>>>>>>>>>>> grant codeBase "jrt:/jdk.vm.compiler" {
>>>>>>>>>>>> permission java.security.AllPermission;
>>>>>>>>>>>> };
>>>>>>>>>>>> 
>>>>>>>>>>>> If -XX:+BootstrapJVMCI -XX:+UseJVMCICompiler are supported, the other question I have is which loader jdk.vm.compiler should be defined?
>>>>>>>>>>>> 
>>>>>>>>>>>> Mandy
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>

More information about the security-dev mailing list