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

[Doug Simon]

> On 29 Jan 2017, at 20:34, Igor Veresov <igor.veresov at oracle.com> wrote:
> 
>> 
>> On Jan 27, 2017, at 3:40 PM, Christian Thalinger <cthalinger at twitter.com> wrote:
>> 
>>> 
>>> On Jan 26, 2017, at 7:40 AM, Doug Simon <doug.simon at oracle.com> wrote:
>>> 
>>>> 
>>>> On 26 Jan 2017, at 17:55, 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?
>>> 
>>> Not sure I understand your question - they cannot be used at any other time apart from runtime.
>> 
>> The question is if these command line options are supported by Oracle in JDK 9.  The answer used to be no but that might have changed.  Someone from Oracle needs to chime in.
> 
> 
> I would imagine that the permissions Doug mentions are required regardless of whether it’s supported on not.

Correct.

Also, sorry for misinterpreting the question Mandy. I thought being experimental means not officially supported. However, I’ve heard that AOT may be supported even though being experimental. In any case, I’m fairly sure using Graal as a JIT is not supported.

-Doug

>> 
>> Having said that, it would be a shame if we don’t make jdk.vm.compiler a trusted system component because it obviously is.
>> 
>> We have to do it at some point anyway so why not now…
>> 
>>> 
>>>>> 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?
>>> 
>>> I’m no expert on class loaders, but I would guess the same loader as jdk.vm.ci.
>>> 
>>> -Doug