RFR: 8177845: Need a mechanism to load Graal

Doug Simon doug.simon at oracle.com
Wed Apr 19 19:27:38 UTC 2017

> On 19 Apr 2017, at 21:04, Mandy Chung <mandy.chung at oracle.com> wrote:
>> On Apr 19, 2017, at 11:55 AM, Christian Thalinger <cthalinger at twitter.com> wrote:
>>> On Apr 19, 2017, at 8:38 AM, Mandy Chung <mandy.chung at 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?


More information about the jigsaw-dev mailing list