RFR: 8177845: Need a mechanism to load Graal

[Doug Simon]

> On 20 Apr 2017, at 10:01, Andrew Haley <aph at redhat.com> wrote:
> 
> On 20/04/17 08:56, Doug Simon wrote:
>> 
>>> On 20 Apr 2017, at 09:46, Andrew Haley <aph at redhat.com> wrote:
>>> 
>>> On 19/04/17 19:55, Christian Thalinger wrote:
>>>> This all makes sense but where is the restriction that only
>>>> jdk.internal.vm.compiler can use jdk.vm.ci.services?  After all,
>>>> this is a security issue.
>>> 
>>> Does that make any sense?  Surely the *user* of a system can call Truffle,
>>> and therefore can call JMCI.
>> 
>> Truffle is completely separate from JVMCI. Only the Graal
>> implementation of TruffleRuntime knows about JVMCI.
> 
> Yes, I am aware of that.  :-)

Ok, sorry for being confused by your statement ;-)

>>> I thought that was the idea.  If you can call Truffle from your own
>>> code, why shouldn't you be able to call JVMCI from your own
>>> compiler?
>> 
>> We may need to add some doPrivileged sections to Graal at some point
>> ensure everything works when running Truffle under a security
>> manager.
> 
> That would be courageous.  But what Christian was saying, I believe,
> was that JVMCI could be restricted to only being available from
> jdk.internal.vm.compiler.

Ah, ok. That would go against the move to make jdk.internal.vm.compiler an upgradeable module as there should not be any qualified exports to an upgradeable module. For this reason, the security of JVMCI relies on exporting as little of the API as possible and having JVMCIPermission checks on the exported methods where necessary.

-Doug