> On 26 Jan 2017, at 17:55, Mandy Chung <mandy.ch...@oracle.com> wrote:
>
>
>> On Jan 26, 2017, at 3:13 AM, Doug Simon <doug.si...@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.
>> 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
