> On 30 Jan 2017, at 17:11, Mandy Chung <mandy.ch...@oracle.com> 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 <doug.si...@oracle.com> 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 <mandy.ch...@oracle.com> 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 <mandy.ch...@oracle.com> 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 <doug.si...@oracle.com> 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 <sean.mul...@oracle.com> 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 >>>>>>>> <thomas.wuerthin...@oracle.com> 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 <mandy.ch...@oracle.com> 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 >>>>>>>>>> <thomas.wuerthin...@oracle.com> 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 <mandy.ch...@oracle.com> >>>>>>>>>>> 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 <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? >>>>>>>>>>>> >>>>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>> >>> >> >
