> 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. > > 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? It’s awfully late in the cycle... > > Does this address the security concerns? Mostly, yes. Thanks. > > -Doug
