> 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]
>> <mailto:[email protected]>> wrote:
>>
>>>
>>> On 26 Jan 2017, at 17:55, Mandy Chung <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>>
>>>> On Jan 26, 2017, at 3:13 AM, Doug Simon <[email protected]
>>>> <mailto:[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.
igor
>
> 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