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