> 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. 2 should check for JVMCIPermission. I'll update the webrev with this change. 3 is harmless from a security perspective in my opinion. 4 checks for JVMCIPermission. 5, 6 and 7 will be removed in a follow bug that updates Graal from upstream (and removes its usage of these methods). Does this address the security concerns? -Doug
