[foreign-abi] minimizing the surface of restricted native access

Ty Young youngty1997 at gmail.com
Fri Nov 29 11:21:35 UTC 2019



On 11/29/19 3:07 AM, Maurizio Cimadamore wrote:
> Hi Ty,
> without entering in the specifics of your example - let's say you know 
> that getpid() is at address 42 (of course the address will be much 
> bigger, and even be a 'negative' Java long in reality).
>
> With the proposed model, you would be able to do:
>
> MemoryAddress pid = MemoryAddress.ofLong(42);
>
> And then you would be able to obtain a MethodHandle out of that, using 
> the SystemABI:
>
> MethodHandle handle = SystemABI.getInstance().downcallHandle(pid, 
> MethodType.methodType(int.class), FunctionDescriptor.of(C_INT));
>
> Then you can call the handle, normally.
>
> The only "unsafe" operation there is here, is the call to SystemABI to 
> obtain the MethodHandle. This is a place where the API has to trust 
> the developer because:
>
> - the entry point address could be invalid
> - the function descriptor could be invalid leading to wrong calling 
> sequence
>
> In all these cases the results of calling an ill-formed handle would 
> be unpredictable (and there's no way to make this API safe - C 
> libraries w/o debugging info have zero info about function signatures, 
> so there's no way to check things - which leaves us in the best 
> effort-land **) - some of these situations can also arise with JNI if 
> the signature of the native method and the underlying C header/impl 
> are out of sync.
>
> But the memory access API (in its ABI-ready incarnation) should give 
> you a way to at least construct a pointer to the desired function.


Thanks for the clarification.


Are there any plans to make jdk.internal.foreign a default export? 
Currently it's one of the seemingly very few "internal" modules that 
aren't exported and I'll have to recompile from source with it exported 
in order to use it.




>
> Maurizio
>
> (**) The VM already has a nice diagnostic option called "-Xcheck:jni" 
> which performs a variety of checks; but, again, this is a best-effort 
> attempt and cannot detect all possible things that can go wrong (such 
> as mismatches between Java signatures and C signatures).


More information about the panama-dev mailing list