I've updated http://cr.openjdk.java.net/~dnsimon/8177845/hotspot/ with these changes:
1. JVMCIServiceLocator.getProvider(Class<S>) is now protected 2. JVMCIServiceLocator.getProviders(Class<S>) now checks JVMCIPermission 3. Rename: jdk.vm.ci.services.internal.JDK9 -> jdk.vm.ci.services.internal.ReflectionAccessJDK -Doug > On 19 Apr 2017, at 23:12, Doug Simon <doug.si...@oracle.com> wrote: > >> >> On 19 Apr 2017, at 21:40, Christian Thalinger <cthalin...@twitter.com> wrote: >> >>> >>> On Apr 19, 2017, at 9:27 AM, Doug Simon <doug.si...@oracle.com> wrote: >>> >>>> >>>> On 19 Apr 2017, at 21:04, Mandy Chung <mandy.ch...@oracle.com> wrote: >>>> >>>> >>>>> On Apr 19, 2017, at 11:55 AM, Christian Thalinger >>>>> <cthalin...@twitter.com> wrote: >>>>> >>>>> >>>>>> On Apr 19, 2017, at 8:38 AM, Mandy Chung <mandy.ch...@oracle.com> wrote: >>>>>> >>>>>> Since jdk.internal.vm.compiler becomes an upgradeable module, it is not >>>>>> hashed with java.base to allow it to be upgraded and there is no >>>>>> integrity check. Such qualified export will be granted to any module >>>>>> named jdk.internal.vm.compiler at runtime. The goal is for upgradeable >>>>>> modules not to use any internal APIs and eliminate the qualified exports. >>>>>> >>>>>> The main thing is that jdk.vm.ci.services API would need to be guarded >>>>>> if it’s used by non-Graal modules. >>>>> >>>>> This all makes sense but where is the restriction that only >>>>> jdk.internal.vm.compiler can use jdk.vm.ci.services? >>>> >>>> It's unqualified and no restriction in this change. >>> >>> The public methods currently in jdk.vm.ci.services are: >>> >>> 1. JVMCIServiceLocator.getProvider(Class<S>) >>> 2. JVMCIServiceLocator.getProviders(Class<S>) >>> 3. Services.initializeJVMCI() >>> 4. Services.getSavedProperties() >>> 5. Services.exportJVMCITo(Class<?>) >>> 6. Services.load(Class<S>) >>> 7. Services.loadSingle(Class<S>, boolean) >>> >>> 1 should be made protected. I'll update the webrev with this change. >> >> Good. >> >>> >>> 2 should check for JVMCIPermission. I'll update the webrev with this change. >> >> Good. >> >>> >>> 3 is harmless from a security perspective in my opinion. >> >> Would be good if one of Oracle’s security engineers could take a quick look >> just to be sure. > > Vladimir, can you please bring this to the attention of the relevant engineer. > >>> >>> 4 checks for JVMCIPermission. >> >> Ok. >> >>> >>> 5, 6 and 7 will be removed in a follow bug that updates Graal from upstream >>> (and removes its usage of these methods). >> >> About this, will this Graal update happen for JDK 9? > > Yes. > >> It’s awfully late in the cycle... > > These are jigsaw related changes and I've been told jigsaw has an FC > exception (although I don't exactly know what that is). > > -Doug
