Quantcast

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

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Doug Simon @ Oracle
Both jdk.vm.ci and jdk.vm.compiler require a number of permissions when a security manager is present. Since neither of these modules is accessible to application code, it should be ok to give them all permissions. This seems to be the approach for a number of other modules including jdk.scripting.nashorn, jdk.dynalink, jdk.jsobject etc. Please review this small change that configures this proposed permission level.

http://cr.openjdk.java.net/~dnsimon/8145337/webrev/
https://bugs.openjdk.java.net/browse/JDK-8145337

-Doug
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Mandy Chung
(dropping jdk9-dev.  security-libs is the appropriate list to review security permission)

> On Jan 23, 2017, at 1:56 PM, Doug Simon <[hidden email]> wrote:
>
> Both jdk.vm.ci and jdk.vm.compiler require a number of permissions when a security manager is present. Since neither of these modules is accessible to application code, it should be ok to give them all permissions. This seems to be the approach for a number of other modules including jdk.scripting.nashorn, jdk.dynalink, jdk.jsobject etc. Please review this small change that configures this proposed permission level.
>
> http://cr.openjdk.java.net/~dnsimon/8145337/webrev/
> https://bugs.openjdk.java.net/browse/JDK-8145337

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.  You can reference JDK tools such as jdk.compiler and jdk.jlink that are not granted with any permission.

Mandy
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Doug Simon @ Oracle

> On 26 Jan 2017, at 03:32, Mandy Chung <[hidden email]> wrote:
>
> (dropping jdk9-dev.  security-libs is the appropriate list to review security permission)
>
>> On Jan 23, 2017, at 1:56 PM, Doug Simon <[hidden email]> wrote:
>>
>> Both jdk.vm.ci and jdk.vm.compiler require a number of permissions when a security manager is present. Since neither of these modules is accessible to application code, it should be ok to give them all permissions. This seems to be the approach for a number of other modules including jdk.scripting.nashorn, jdk.dynalink, jdk.jsobject etc. Please review this small change that configures this proposed permission level.
>>
>> http://cr.openjdk.java.net/~dnsimon/8145337/webrev/
>> https://bugs.openjdk.java.net/browse/JDK-8145337
>
> 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):

grant codeBase "jrt:/jdk.vm.compiler" {
    // org.graalvm.compiler.hotspot.HotSpotGraalJVMCIServiceLocator.<init>
    permission jdk.vm.ci.services.JVMCIPermission;

    // org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.getSavedProperties
    permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.misc";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";

    // org.graalvm.compiler.core.common.util.ModuleAPI.<clinit>
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.module";

    // org.graalvm.compiler.options.OptionValue.<clinit>
    permission java.util.PropertyPermission "graal.profileOptionValue", "read";

    // org.graalvm.compiler.debug.Debug.<clinit>
    permission java.util.PropertyPermission "*", "read,write";

    // org.graalvm.compiler.core.common.UnsafeAccess.initUnsafe
    permission java.lang.RuntimePermission "accessClassInPackage.sun.misc";

    // org.graalvm.compiler.hotspot.BootstrapWatchDog.<init>
    permission java.lang.RuntimePermission "modifyThread";
    permission java.lang.RuntimePermission "modifyThreadGroup";

    // org.graalvm.compiler.hotspot.replacements.SHA2Substitutions.<clinit>
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.provider";

    // org.graalvm.compiler.nodes.graphbuilderconf.InvocationPlugins.resolveClass
    permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.reflect";
    permission java.lang.RuntimePermission "accessClassInPackage.oracle.jrockit.jfr.jdkevents";
};

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.

For comparison, below are all the modules currently given java.security.AllPermission by lib/security/default.policy:

grant codeBase "jrt:/java.activation" {
    permission java.security.AllPermission;
};

grant codeBase "jrt:/java.compiler" {
    permission java.security.AllPermission;
};

grant codeBase "jrt:/java.corba" {
    permission java.security.AllPermission;
};

grant codeBase "jrt:/jdk.incubator.httpclient" {
};

grant codeBase "jrt:/java.scripting" {
    permission java.security.AllPermission;
};

grant codeBase "jrt:/java.security.jgss" {
    permission java.security.AllPermission;
};

grant codeBase "jrt:/java.sql" {
    permission java.security.AllPermission;
};

grant codeBase "jrt:/java.sql.rowset" {
    permission java.security.AllPermission;
};

grant codeBase "jrt:/jdk.dynalink" {
    permission java.security.AllPermission;
};

grant codeBase "jrt:/jdk.internal.le" {
    permission java.security.AllPermission;
};

grant codeBase "jrt:/jdk.jsobject" {
    permission java.security.AllPermission;
};

grant codeBase "jrt:/jdk.naming.dns" {
    permission java.security.AllPermission;
};

grant codeBase "jrt:/jdk.scripting.nashorn" {
    permission java.security.AllPermission;
};

grant codeBase "jrt:/jdk.scripting.nashorn.shell" {
    permission java.security.AllPermission;
};

grant codeBase "jrt:/jdk.security.auth" {
    permission java.security.AllPermission;
};

grant codeBase "jrt:/jdk.security.jgss" {
    permission java.security.AllPermission;
};

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Mandy Chung

> On Jan 26, 2017, at 3:13 AM, Doug Simon <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Doug Simon @ Oracle

> On 26 Jan 2017, at 17:55, Mandy Chung <[hidden email]> wrote:
>
>
>> On Jan 26, 2017, at 3:13 AM, Doug Simon <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Christian Thalinger-4

On Jan 26, 2017, at 7:40 AM, Doug Simon <[hidden email]> wrote:


On 26 Jan 2017, at 17:55, Mandy Chung <[hidden email]> wrote:


On Jan 26, 2017, at 3:13 AM, Doug Simon <[hidden email]> 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.

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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Igor Veresov

On Jan 27, 2017, at 3:40 PM, Christian Thalinger <[hidden email]> wrote:


On Jan 26, 2017, at 7:40 AM, Doug Simon <[hidden email]> wrote:


On 26 Jan 2017, at 17:55, Mandy Chung <[hidden email]> wrote:


On Jan 26, 2017, at 3:13 AM, Doug Simon <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Doug Simon @ Oracle

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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Doug Simon @ Oracle
In reply to this post by Mandy Chung

> On 30 Jan 2017, at 17:11, Mandy Chung <[hidden email]> wrote:
>
> Moving it to platform class loader is okay with me.  I’m still unsure if jdk.vm.compiler should be defined by the boot loader instead and you may want to look into in a future release.

We also want jdk.vm.compiler to be upgradeable (as discussed in another thread) so that we can test newer development versions of Graal as the VM JIT via --upgrade-module-path instead of having to rebuild the JDK. As far as I understand, this means it cannot be defined by the boot loader.

> You can change make/common/Modules.gmk to move it to the PLATFORM_MODULES list.

I’ve extended the webrev with that change - please re-review:

http://cr.openjdk.java.net/~dnsimon/8145337_make/webrev

Strangely, there was no existing declaration of jdk.vm.compiler in Modules.gmk.

BTW, I never answered your question:

"How does JVMCI call out to jdk.vm.compiler?  does it load classes using Class::forName with the system class loader?”

It uses JVMCIServiceLocator[1] which is a mechanism built on the standard ServiceLoader.

-Doug

[1] http://hg.openjdk.java.net/jdk9/hs/hotspot/file/2c44cff993b8/src/jdk.vm.ci/share/classes/jdk.vm.ci.services/src/jdk/vm/ci/services/JVMCIServiceLocator.java#l29

>
>> On Jan 29, 2017, at 12:40 PM, Doug Simon <[hidden email]> wrote:
>>
>> Both jdk.vm.ci and jdk.vm.compiler should be considered part of the VM since they have the same capabilities as Unsafe. Arguably they could be considered even more trusted as they make it easier to do what one could (in theory) do with Unsafe. However, maybe they can still be defined by the platform class loader as 17 of 27 modules in default.policy[1] are granted AllPermission.
>>
>> -Doug
>>
>> [1] http://hg.openjdk.java.net/jdk9/dev/jdk/file/tip/src/java.base/share/lib/security/default.policy
>>
>>> On 28 Jan 2017, at 02:00, Mandy Chung <[hidden email]> wrote:
>>>
>>> To clarify my question, I am not objecting fo jdk.vm.compiler be included in the runtime. I’m trying to figure what the right loader should be.  It seems to me that it should be defined by the boot loader, as it is part of the VM.  However, another thread suggests that you want jdk.vm.compiler to be upgradeable as Graal version requires other dependencies.  We only support modules defined by the platform class loader be upgradeable.
>>>
>>> Mandy
>>>
>>>> On Jan 27, 2017, at 9:52 AM, Mandy Chung <[hidden email]> wrote:
>>>>
>>>> I have been wondering what defining loader jdk.vm.compiler should be, if used for JIT at runtime.  That’s one reason I mentioned that the VM does not delegate to any of its child loader.
>>>>
>>>> How does JVMCI call out to jdk.vm.compiler?  does it load classes using Class::forName with the system class loader?
>>>>
>>>> Mandy
>>>>
>>>>> On Jan 27, 2017, at 9:23 AM, Doug Simon <[hidden email]> wrote:
>>>>>
>>>>> Since jdk.vm.compiler can be used as the VM compiler, shouldn't it be loaded by the platform class loader? I hope jdk.vm.ci is using the platform class loader. Where is this decision encoded?
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>>> On Jan 27, 2017, at 5:45 PM, Sean Mullan <[hidden email]> wrote:
>>>>>>
>>>>>> I would need more time to understand the issue, but default.policy is not the right place to be granting these permissions, since this module is not loaded by the platform class loader. From the first 3 lines of default.policy:
>>>>>>
>>>>>> //
>>>>>> // Permissions required by modules stored in a run-time image and loaded
>>>>>> // by the platform class loader.
>>>>>>
>>>>>> --Sean
>>>>>>
>>>>>>> On 1/26/17 7:36 PM, Mandy Chung wrote:
>>>>>>> I’ll let Drew and Sean to advise on this. (Drew, Sean - sorry for missing to include you in this offlist thread).
>>>>>>>
>>>>>>> jdk.vm.compiler is defined by the application class loader.  It’d be the first one in JDK if we grant it with AllPermissions and so the security team should be the experts to review this.
>>>>>>>
>>>>>>> Mandy
>>>>>>>
>>>>>>>> On Jan 26, 2017, at 1:17 PM, Thomas Wuerthinger <[hidden email]> wrote:
>>>>>>>>
>>>>>>>> While the addition of "-Djava.security.policy=jit.policy” is not an issue, we would like to avoid the need for additional files.
>>>>>>>>
>>>>>>>> To me -XX:+UseJVMCICompiler should pretty much imply that “jdk.vm.compiler” will be granted java.security.AllPermission. The code running in the “jdk.vm.compiler” module can install machine code in the VM. I don’t think there is a scenario in which one would like to run any “untrusted” code as part of this module.
>>>>>>>>
>>>>>>>> - thomas
>>>>>>>>
>>>>>>>>
>>>>>>>>> On 26 Jan 2017, at 19:05, Mandy Chung <[hidden email]> wrote:
>>>>>>>>>
>>>>>>>>> Sicen it’s experimental, when -Djava.security.manager is set, is it an option to require to set -Djava.security.policy as well?
>>>>>>>>>
>>>>>>>>> java -server -XX:+UnlockExperimentalVMOptions -Djava.security.manager -Djava.security.policy=jit.policy -XX:+BootstrapJVMCI -XX:+UseJVMCICompiler -version
>>>>>>>>>
>>>>>>>>> $ cat jit.policy
>>>>>>>>> grant codeBase "jrt:/jdk.vm.compiler" {
>>>>>>>>> permission java.security.AllPermission;
>>>>>>>>> };
>>>>>>>>>
>>>>>>>>> jdk.vm.compiler is defined by the application class loader.  The bootstrap class loader doesn’t delegate to the application class loader when resolving a class that is initiated from a class that is defined by the bootstrap class loader.  I don’t know how VM/JIT interacts with jdk.vm.compiler.   Just to mention it.
>>>>>>>>>
>>>>>>>>> Mandy
>>>>>>>>>
>>>>>>>>>> On Jan 26, 2017, at 9:34 AM, Thomas Wuerthinger <[hidden email]> wrote:
>>>>>>>>>>
>>>>>>>>>> Mandy,
>>>>>>>>>>
>>>>>>>>>> We do have an agreement that part of the goal for JVMCI is to be able to run under an experimental flag Graal as a JIT in JDK9 in order for external folks to test Graal as a JIT. Not being able to do so would be considered a blocker for us.
>>>>>>>>>>
>>>>>>>>>> - thomas
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On 26 Jan 2017, at 17:57, Mandy Chung <[hidden email]> wrote:
>>>>>>>>>>>
>>>>>>>>>>> (offlist)
>>>>>>>>>>>
>>>>>>>>>>> Hi Doug,
>>>>>>>>>>>
>>>>>>>>>>> I guess this may be coming from security assessment.  As I understand, jdk.vm.compiler is not used for JIT in JDK 9.  Why do you need to ensure jdk.vm.compiler can run with security manager out of the box?
>>>>>>>>>>>
>>>>>>>>>>> Mandy
>>>>>>>>>>>
>>>>>>>>>>>> On Jan 26, 2017, at 8:55 AM, Mandy Chung <[hidden email]> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>> On Jan 26, 2017, at 3:13 AM, Doug Simon <[hidden email]> 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
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Mandy Chung

> On Jan 30, 2017, at 10:38 AM, Doug Simon <[hidden email]> wrote:
>
> I’ve extended the webrev with that change - please re-review:
>
> http://cr.openjdk.java.net/~dnsimon/8145337_make/webrev
>

+1

> Strangely, there was no existing declaration of jdk.vm.compiler in Modules.gmk.
>

Default is to be defined by the application class loader.  The build will find all modules from the source. There is no need to list all modules.

> BTW, I never answered your question:
>
> "How does JVMCI call out to jdk.vm.compiler?  does it load classes using Class::forName with the system class loader?”
>
> It uses JVMCIServiceLocator[1] which is a mechanism built on the standard ServiceLoader.

Thanks for the pointer. That confirms my understanding that loads the service providers using the system class loader.

Mandy
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Doug Simon @ Oracle

> On 30 Jan 2017, at 21:55, Mandy Chung <[hidden email]> wrote:
>
>
>> On Jan 30, 2017, at 10:38 AM, Doug Simon <[hidden email]> wrote:
>>
>> I’ve extended the webrev with that change - please re-review:
>>
>> http://cr.openjdk.java.net/~dnsimon/8145337_make/webrev
>>
>
> +1

Thanks. Is that a “Reviewed”?

I think I should get at least one sign-off from the security team.

Also, since this is effectively making jdk.vm.compiler an upgradeable module, what’s the implication for it being a hash-checked module? It seems like these changes effectively achieve what I was requesting with https://bugs.openjdk.java.net/browse/JDK-8171448.

-Doug

>
>> Strangely, there was no existing declaration of jdk.vm.compiler in Modules.gmk.
>>
>
> Default is to be defined by the application class loader.  The build will find all modules from the source. There is no need to list all modules.
>
>> BTW, I never answered your question:
>>
>> "How does JVMCI call out to jdk.vm.compiler?  does it load classes using Class::forName with the system class loader?”
>>
>> It uses JVMCIServiceLocator[1] which is a mechanism built on the standard ServiceLoader.
>
> Thanks for the pointer. That confirms my understanding that loads the service providers using the system class loader.
>
> Mandy

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Mandy Chung

> On Jan 30, 2017, at 1:36 PM, Doug Simon <[hidden email]> wrote:
>
>
>> On 30 Jan 2017, at 21:55, Mandy Chung <[hidden email]> wrote:
>>
>>
>>> On Jan 30, 2017, at 10:38 AM, Doug Simon <[hidden email]> wrote:
>>>
>>> I’ve extended the webrev with that change - please re-review:
>>>
>>> http://cr.openjdk.java.net/~dnsimon/8145337_make/webrev
>>>
>>
>> +1
>
> Thanks. Is that a “Reviewed”?
>

Sorry. I only noticed now that you added this to UPGRADEABLE_MODULE.   Please add it only to PLATFORM_MODULES list instead.

Making it an upgradeable module is a separate issue.  I suggest you reopen JDK-8171448.  Specifically, since upgradeable modules are not tied with java.base, our goal for JDK 9 is to eliminate qualified exports from JDK modules to upgradeable modules, e.g. JDK-8170116, JDK-8166745, JDK-8161549.

> I think I should get at least one sign-off from the security team.
>

Hope Sean will review this one.  Please send an updated webrev.

> Also, since this is effectively making jdk.vm.compiler an upgradeable module,

No it does not.

> what’s the implication for it being a hash-checked module?

When a module M is recorded in the ModuleHashes attribute of java.base, the runtime will check if module M resolved in the graph matches the one tied with java.base when created at build time; if not, it will fail.  If an upgradeable module

> It seems like these changes effectively achieve what I was requesting with https://bugs.openjdk.java.net/browse/JDK-8171448.

JDK-8145337 is about the security permission.  It’s better to separate this review from JDK-8171448.

Mandy

>
> -Doug
>
>>
>>> Strangely, there was no existing declaration of jdk.vm.compiler in Modules.gmk.
>>>
>>
>> Default is to be defined by the application class loader.  The build will find all modules from the source. There is no need to list all modules.
>>
>>> BTW, I never answered your question:
>>>
>>> "How does JVMCI call out to jdk.vm.compiler?  does it load classes using Class::forName with the system class loader?”
>>>
>>> It uses JVMCIServiceLocator[1] which is a mechanism built on the standard ServiceLoader.
>>
>> Thanks for the pointer. That confirms my understanding that loads the service providers using the system class loader.
>>
>> Mandy
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Doug Simon @ Oracle
I’ve reworked the webrev as requested to make jdk.vm.compiler a non-upgradeable platform module, this allowing it to be mentioned in default.policy:

http://cr.openjdk.java.net/~dnsimon/8145337/

-Doug

> On 30 Jan 2017, at 22:53, Mandy Chung <[hidden email]> wrote:
>
>>
>> On Jan 30, 2017, at 1:36 PM, Doug Simon <[hidden email]> wrote:
>>
>>
>>> On 30 Jan 2017, at 21:55, Mandy Chung <[hidden email]> wrote:
>>>
>>>
>>>> On Jan 30, 2017, at 10:38 AM, Doug Simon <[hidden email]> wrote:
>>>>
>>>> I’ve extended the webrev with that change - please re-review:
>>>>
>>>> http://cr.openjdk.java.net/~dnsimon/8145337_make/webrev
>>>>
>>>
>>> +1
>>
>> Thanks. Is that a “Reviewed”?
>>
>
> Sorry. I only noticed now that you added this to UPGRADEABLE_MODULE.   Please add it only to PLATFORM_MODULES list instead.
>
> Making it an upgradeable module is a separate issue.  I suggest you reopen JDK-8171448.  Specifically, since upgradeable modules are not tied with java.base, our goal for JDK 9 is to eliminate qualified exports from JDK modules to upgradeable modules, e.g. JDK-8170116, JDK-8166745, JDK-8161549.
>
>> I think I should get at least one sign-off from the security team.
>>
>
> Hope Sean will review this one.  Please send an updated webrev.
>
>> Also, since this is effectively making jdk.vm.compiler an upgradeable module,
>
> No it does not.
>
>> what’s the implication for it being a hash-checked module?
>
> When a module M is recorded in the ModuleHashes attribute of java.base, the runtime will check if module M resolved in the graph matches the one tied with java.base when created at build time; if not, it will fail.  If an upgradeable module
>
>> It seems like these changes effectively achieve what I was requesting with https://bugs.openjdk.java.net/browse/JDK-8171448.
>
> JDK-8145337 is about the security permission.  It’s better to separate this review from JDK-8171448.
>
> Mandy
>
>>
>> -Doug
>>
>>>
>>>> Strangely, there was no existing declaration of jdk.vm.compiler in Modules.gmk.
>>>>
>>>
>>> Default is to be defined by the application class loader.  The build will find all modules from the source. There is no need to list all modules.
>>>
>>>> BTW, I never answered your question:
>>>>
>>>> "How does JVMCI call out to jdk.vm.compiler?  does it load classes using Class::forName with the system class loader?”
>>>>
>>>> It uses JVMCIServiceLocator[1] which is a mechanism built on the standard ServiceLoader.
>>>
>>> Thanks for the pointer. That confirms my understanding that loads the service providers using the system class loader.
>>>
>>> Mandy

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Sean Mullan
Couple of comments:

- jdk.vm.ci is already loaded by the boot loader so it is implicitly
granted AllPermission and does not need an entry in default.policy.

- all internal APIs in the jdk.vm.compiler module will now be restricted
by default by SecurityManager::checkPackageAccess(), so if you have any
code or tests running with a SecurityManager that are accessing internal
APIs in the jdk.vm.compiler module, you will need to grant them an
appropriate "accessClassInPackage" RuntimePermission in addition to any
--add-exports option you are using to break through encapsulation.

--Sean

On 2/1/17 6:07 AM, Doug Simon wrote:

> I’ve reworked the webrev as requested to make jdk.vm.compiler a non-upgradeable platform module, this allowing it to be mentioned in default.policy:
>
> http://cr.openjdk.java.net/~dnsimon/8145337/
>
> -Doug
>
>> On 30 Jan 2017, at 22:53, Mandy Chung <[hidden email]> wrote:
>>
>>>
>>> On Jan 30, 2017, at 1:36 PM, Doug Simon <[hidden email]> wrote:
>>>
>>>
>>>> On 30 Jan 2017, at 21:55, Mandy Chung <[hidden email]> wrote:
>>>>
>>>>
>>>>> On Jan 30, 2017, at 10:38 AM, Doug Simon <[hidden email]> wrote:
>>>>>
>>>>> I’ve extended the webrev with that change - please re-review:
>>>>>
>>>>> http://cr.openjdk.java.net/~dnsimon/8145337_make/webrev
>>>>>
>>>>
>>>> +1
>>>
>>> Thanks. Is that a “Reviewed”?
>>>
>>
>> Sorry. I only noticed now that you added this to UPGRADEABLE_MODULE.   Please add it only to PLATFORM_MODULES list instead.
>>
>> Making it an upgradeable module is a separate issue.  I suggest you reopen JDK-8171448.  Specifically, since upgradeable modules are not tied with java.base, our goal for JDK 9 is to eliminate qualified exports from JDK modules to upgradeable modules, e.g. JDK-8170116, JDK-8166745, JDK-8161549.
>>
>>> I think I should get at least one sign-off from the security team.
>>>
>>
>> Hope Sean will review this one.  Please send an updated webrev.
>>
>>> Also, since this is effectively making jdk.vm.compiler an upgradeable module,
>>
>> No it does not.
>>
>>> what’s the implication for it being a hash-checked module?
>>
>> When a module M is recorded in the ModuleHashes attribute of java.base, the runtime will check if module M resolved in the graph matches the one tied with java.base when created at build time; if not, it will fail.  If an upgradeable module
>>
>>> It seems like these changes effectively achieve what I was requesting with https://bugs.openjdk.java.net/browse/JDK-8171448.
>>
>> JDK-8145337 is about the security permission.  It’s better to separate this review from JDK-8171448.
>>
>> Mandy
>>
>>>
>>> -Doug
>>>
>>>>
>>>>> Strangely, there was no existing declaration of jdk.vm.compiler in Modules.gmk.
>>>>>
>>>>
>>>> Default is to be defined by the application class loader.  The build will find all modules from the source. There is no need to list all modules.
>>>>
>>>>> BTW, I never answered your question:
>>>>>
>>>>> "How does JVMCI call out to jdk.vm.compiler?  does it load classes using Class::forName with the system class loader?”
>>>>>
>>>>> It uses JVMCIServiceLocator[1] which is a mechanism built on the standard ServiceLoader.
>>>>
>>>> Thanks for the pointer. That confirms my understanding that loads the service providers using the system class loader.
>>>>
>>>> Mandy
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Doug Simon @ Oracle

> On 1 Feb 2017, at 20:54, Sean Mullan <[hidden email]> wrote:
>
> Couple of comments:
>
> - jdk.vm.ci is already loaded by the boot loader so it is implicitly granted AllPermission and does not need an entry in default.policy.

Thanks - I removed it.

> - all internal APIs in the jdk.vm.compiler module will now be restricted by default by SecurityManager::checkPackageAccess(), so if you have any code or tests running with a SecurityManager that are accessing internal APIs in the jdk.vm.compiler module, you will need to grant them an appropriate "accessClassInPackage" RuntimePermission in addition to any --add-exports option you are using to break through encapsulation.

Vladimir, does the AOT need to run with a SecurityManager and if so, I assume the qualified exports from jdk.vm.compiler to jdk.aot will allow it to run without needed an extra policy file?

-Doug

> On 2/1/17 6:07 AM, Doug Simon wrote:
>> I’ve reworked the webrev as requested to make jdk.vm.compiler a non-upgradeable platform module, this allowing it to be mentioned in default.policy:
>>
>> http://cr.openjdk.java.net/~dnsimon/8145337/
>>
>> -Doug
>>
>>> On 30 Jan 2017, at 22:53, Mandy Chung <[hidden email]> wrote:
>>>
>>>>
>>>> On Jan 30, 2017, at 1:36 PM, Doug Simon <[hidden email]> wrote:
>>>>
>>>>
>>>>> On 30 Jan 2017, at 21:55, Mandy Chung <[hidden email]> wrote:
>>>>>
>>>>>
>>>>>> On Jan 30, 2017, at 10:38 AM, Doug Simon <[hidden email]> wrote:
>>>>>>
>>>>>> I’ve extended the webrev with that change - please re-review:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~dnsimon/8145337_make/webrev
>>>>>>
>>>>>
>>>>> +1
>>>>
>>>> Thanks. Is that a “Reviewed”?
>>>>
>>>
>>> Sorry. I only noticed now that you added this to UPGRADEABLE_MODULE.   Please add it only to PLATFORM_MODULES list instead.
>>>
>>> Making it an upgradeable module is a separate issue.  I suggest you reopen JDK-8171448.  Specifically, since upgradeable modules are not tied with java.base, our goal for JDK 9 is to eliminate qualified exports from JDK modules to upgradeable modules, e.g. JDK-8170116, JDK-8166745, JDK-8161549.
>>>
>>>> I think I should get at least one sign-off from the security team.
>>>>
>>>
>>> Hope Sean will review this one.  Please send an updated webrev.
>>>
>>>> Also, since this is effectively making jdk.vm.compiler an upgradeable module,
>>>
>>> No it does not.
>>>
>>>> what’s the implication for it being a hash-checked module?
>>>
>>> When a module M is recorded in the ModuleHashes attribute of java.base, the runtime will check if module M resolved in the graph matches the one tied with java.base when created at build time; if not, it will fail.  If an upgradeable module
>>>
>>>> It seems like these changes effectively achieve what I was requesting with https://bugs.openjdk.java.net/browse/JDK-8171448.
>>>
>>> JDK-8145337 is about the security permission.  It’s better to separate this review from JDK-8171448.
>>>
>>> Mandy
>>>
>>>>
>>>> -Doug
>>>>
>>>>>
>>>>>> Strangely, there was no existing declaration of jdk.vm.compiler in Modules.gmk.
>>>>>>
>>>>>
>>>>> Default is to be defined by the application class loader.  The build will find all modules from the source. There is no need to list all modules.
>>>>>
>>>>>> BTW, I never answered your question:
>>>>>>
>>>>>> "How does JVMCI call out to jdk.vm.compiler?  does it load classes using Class::forName with the system class loader?”
>>>>>>
>>>>>> It uses JVMCIServiceLocator[1] which is a mechanism built on the standard ServiceLoader.
>>>>>
>>>>> Thanks for the pointer. That confirms my understanding that loads the service providers using the system class loader.
>>>>>
>>>>> Mandy
>>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Vladimir Kozlov
AOT tool jaotc does not run with SecurityManager. We assume it runs in secure environment and it does not access any external resources.

Thanks
Vladimir

> On Feb 1, 2017, at 12:03 PM, Doug Simon <[hidden email]> wrote:
>
>
>> On 1 Feb 2017, at 20:54, Sean Mullan <[hidden email]> wrote:
>>
>> Couple of comments:
>>
>> - jdk.vm.ci is already loaded by the boot loader so it is implicitly granted AllPermission and does not need an entry in default.policy.
>
> Thanks - I removed it.
>
>> - all internal APIs in the jdk.vm.compiler module will now be restricted by default by SecurityManager::checkPackageAccess(), so if you have any code or tests running with a SecurityManager that are accessing internal APIs in the jdk.vm.compiler module, you will need to grant them an appropriate "accessClassInPackage" RuntimePermission in addition to any --add-exports option you are using to break through encapsulation.
>
> Vladimir, does the AOT need to run with a SecurityManager and if so, I assume the qualified exports from jdk.vm.compiler to jdk.aot will allow it to run without needed an extra policy file?
>
> -Doug
>
>>> On 2/1/17 6:07 AM, Doug Simon wrote:
>>> I’ve reworked the webrev as requested to make jdk.vm.compiler a non-upgradeable platform module, this allowing it to be mentioned in default.policy:
>>>
>>> http://cr.openjdk.java.net/~dnsimon/8145337/
>>>
>>> -Doug
>>>
>>>>> On 30 Jan 2017, at 22:53, Mandy Chung <[hidden email]> wrote:
>>>>>
>>>>>
>>>>> On Jan 30, 2017, at 1:36 PM, Doug Simon <[hidden email]> wrote:
>>>>>
>>>>>
>>>>>> On 30 Jan 2017, at 21:55, Mandy Chung <[hidden email]> wrote:
>>>>>>
>>>>>>
>>>>>>> On Jan 30, 2017, at 10:38 AM, Doug Simon <[hidden email]> wrote:
>>>>>>>
>>>>>>> I’ve extended the webrev with that change - please re-review:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~dnsimon/8145337_make/webrev
>>>>>>>
>>>>>>
>>>>>> +1
>>>>>
>>>>> Thanks. Is that a “Reviewed”?
>>>>>
>>>>
>>>> Sorry. I only noticed now that you added this to UPGRADEABLE_MODULE.   Please add it only to PLATFORM_MODULES list instead.
>>>>
>>>> Making it an upgradeable module is a separate issue.  I suggest you reopen JDK-8171448.  Specifically, since upgradeable modules are not tied with java.base, our goal for JDK 9 is to eliminate qualified exports from JDK modules to upgradeable modules, e.g. JDK-8170116, JDK-8166745, JDK-8161549.
>>>>
>>>>> I think I should get at least one sign-off from the security team.
>>>>>
>>>>
>>>> Hope Sean will review this one.  Please send an updated webrev.
>>>>
>>>>> Also, since this is effectively making jdk.vm.compiler an upgradeable module,
>>>>
>>>> No it does not.
>>>>
>>>>> what’s the implication for it being a hash-checked module?
>>>>
>>>> When a module M is recorded in the ModuleHashes attribute of java.base, the runtime will check if module M resolved in the graph matches the one tied with java.base when created at build time; if not, it will fail.  If an upgradeable module
>>>>
>>>>> It seems like these changes effectively achieve what I was requesting with https://bugs.openjdk.java.net/browse/JDK-8171448.
>>>>
>>>> JDK-8145337 is about the security permission.  It’s better to separate this review from JDK-8171448.
>>>>
>>>> Mandy
>>>>
>>>>>
>>>>> -Doug
>>>>>
>>>>>>
>>>>>>> Strangely, there was no existing declaration of jdk.vm.compiler in Modules.gmk.
>>>>>>>
>>>>>>
>>>>>> Default is to be defined by the application class loader.  The build will find all modules from the source. There is no need to list all modules.
>>>>>>
>>>>>>> BTW, I never answered your question:
>>>>>>>
>>>>>>> "How does JVMCI call out to jdk.vm.compiler?  does it load classes using Class::forName with the system class loader?”
>>>>>>>
>>>>>>> It uses JVMCIServiceLocator[1] which is a mechanism built on the standard ServiceLoader.
>>>>>>
>>>>>> Thanks for the pointer. That confirms my understanding that loads the service providers using the system class loader.
>>>>>>
>>>>>> Mandy
>>>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Doug Simon @ Oracle

> On 1 Feb 2017, at 22:19, Vladimir Kozlov <[hidden email]> wrote:
>
> AOT tool jaotc does not run with SecurityManager. We assume it runs in secure environment and it does not access any external resources.

Great.

Can I now consider this change reviewed and integrate it?

-Doug

>> On Feb 1, 2017, at 12:03 PM, Doug Simon <[hidden email]> wrote:
>>
>>
>>> On 1 Feb 2017, at 20:54, Sean Mullan <[hidden email]> wrote:
>>>
>>> Couple of comments:
>>>
>>> - jdk.vm.ci is already loaded by the boot loader so it is implicitly granted AllPermission and does not need an entry in default.policy.
>>
>> Thanks - I removed it.
>>
>>> - all internal APIs in the jdk.vm.compiler module will now be restricted by default by SecurityManager::checkPackageAccess(), so if you have any code or tests running with a SecurityManager that are accessing internal APIs in the jdk.vm.compiler module, you will need to grant them an appropriate "accessClassInPackage" RuntimePermission in addition to any --add-exports option you are using to break through encapsulation.
>>
>> Vladimir, does the AOT need to run with a SecurityManager and if so, I assume the qualified exports from jdk.vm.compiler to jdk.aot will allow it to run without needed an extra policy file?
>>
>> -Doug
>>
>>>> On 2/1/17 6:07 AM, Doug Simon wrote:
>>>> I’ve reworked the webrev as requested to make jdk.vm.compiler a non-upgradeable platform module, this allowing it to be mentioned in default.policy:
>>>>
>>>> http://cr.openjdk.java.net/~dnsimon/8145337/
>>>>
>>>> -Doug
>>>>
>>>>>> On 30 Jan 2017, at 22:53, Mandy Chung <[hidden email]> wrote:
>>>>>>
>>>>>>
>>>>>> On Jan 30, 2017, at 1:36 PM, Doug Simon <[hidden email]> wrote:
>>>>>>
>>>>>>
>>>>>>> On 30 Jan 2017, at 21:55, Mandy Chung <[hidden email]> wrote:
>>>>>>>
>>>>>>>
>>>>>>>> On Jan 30, 2017, at 10:38 AM, Doug Simon <[hidden email]> wrote:
>>>>>>>>
>>>>>>>> I’ve extended the webrev with that change - please re-review:
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~dnsimon/8145337_make/webrev
>>>>>>>>
>>>>>>>
>>>>>>> +1
>>>>>>
>>>>>> Thanks. Is that a “Reviewed”?
>>>>>>
>>>>>
>>>>> Sorry. I only noticed now that you added this to UPGRADEABLE_MODULE.   Please add it only to PLATFORM_MODULES list instead.
>>>>>
>>>>> Making it an upgradeable module is a separate issue.  I suggest you reopen JDK-8171448.  Specifically, since upgradeable modules are not tied with java.base, our goal for JDK 9 is to eliminate qualified exports from JDK modules to upgradeable modules, e.g. JDK-8170116, JDK-8166745, JDK-8161549.
>>>>>
>>>>>> I think I should get at least one sign-off from the security team.
>>>>>>
>>>>>
>>>>> Hope Sean will review this one.  Please send an updated webrev.
>>>>>
>>>>>> Also, since this is effectively making jdk.vm.compiler an upgradeable module,
>>>>>
>>>>> No it does not.
>>>>>
>>>>>> what’s the implication for it being a hash-checked module?
>>>>>
>>>>> When a module M is recorded in the ModuleHashes attribute of java.base, the runtime will check if module M resolved in the graph matches the one tied with java.base when created at build time; if not, it will fail.  If an upgradeable module
>>>>>
>>>>>> It seems like these changes effectively achieve what I was requesting with https://bugs.openjdk.java.net/browse/JDK-8171448.
>>>>>
>>>>> JDK-8145337 is about the security permission.  It’s better to separate this review from JDK-8171448.
>>>>>
>>>>> Mandy
>>>>>
>>>>>>
>>>>>> -Doug
>>>>>>
>>>>>>>
>>>>>>>> Strangely, there was no existing declaration of jdk.vm.compiler in Modules.gmk.
>>>>>>>>
>>>>>>>
>>>>>>> Default is to be defined by the application class loader.  The build will find all modules from the source. There is no need to list all modules.
>>>>>>>
>>>>>>>> BTW, I never answered your question:
>>>>>>>>
>>>>>>>> "How does JVMCI call out to jdk.vm.compiler?  does it load classes using Class::forName with the system class loader?”
>>>>>>>>
>>>>>>>> It uses JVMCIServiceLocator[1] which is a mechanism built on the standard ServiceLoader.
>>>>>>>
>>>>>>> Thanks for the pointer. That confirms my understanding that loads the service providers using the system class loader.
>>>>>>>
>>>>>>> Mandy
>>>>
>>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Sean Mullan
On 2/1/17 4:27 PM, Doug Simon wrote:
> Can I now consider this change reviewed and integrate it?

Yes.

--Sean
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Mandy Chung
In reply to this post by Doug Simon @ Oracle

> On Feb 1, 2017, at 3:07 AM, Doug Simon <[hidden email]> wrote:
>
> I’ve reworked the webrev as requested to make jdk.vm.compiler a non-upgradeable platform module, this allowing it to be mentioned in default.policy:
>
> http://cr.openjdk.java.net/~dnsimon/8145337/

Looks good.

Mandy
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Alan Bateman


On 02/02/2017 02:12, Mandy Chung wrote:
>> On Feb 1, 2017, at 3:07 AM, Doug Simon <[hidden email]> wrote:
>>
>> I’ve reworked the webrev as requested to make jdk.vm.compiler a non-upgradeable platform module, this allowing it to be mentioned in default.policy:
>>
>> http://cr.openjdk.java.net/~dnsimon/8145337/
> Looks good.
>
Looks okay to me too.

-Alan.
Loading...