> On 29 Jan 2017, at 20:34, Igor Veresov <[email protected]> wrote:
>
>>
>> On Jan 27, 2017, at 3:40 PM, Christian Thalinger <[email protected]>
>> wrote:
>>
>>>
>>> On Jan 26, 2017, at 7:40 AM, Doug Simon <[email protected]> wrote:
>>>
>>>>
>>>> On 26 Jan 2017, at 17:55, Mandy Chung <[email protected]> wrote:
>>>>
>>>>
>>>>> On Jan 26, 2017, at 3:13 AM, Doug Simon <[email protected]> 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
