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

[Maurizio Cimadamore]

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.

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).




On 29/11/2019 02:15, Ty Young wrote:
> Hi Maurizio,
>
>
> Appreciate the attempt to offer a solution to the lack of lower level 
> "unsafe" memory access. Last email thread that this was discussed I 
> never really explained why I want/needed it, so I guess I'll do that now.
>
>
> To summarize, I'm using Project Panama to create a common, high level 
> abstractions over Nvidia's various C APIs that is both 
> cross-platform(providing the platform supports the API to begin with) 
> and easy to use for Java. For NVML(cross-platform) and NVXCtrl(Linux), 
> Nvidia provides the full headers for those APIs which is great since 
> the java.foreign API can be used which is really nice. They do not, 
> however, provide complete headers for the Windows specific "NVAPI"... 
> that is under NDA and only organizations such as board partners(think 
> ASUS, MSI, EVGA, etc) have access to them.
>
>
> That, however, doesn't mean you can't get your hands a little dirty 
> and still get access. Someone made a blog post[1] detailing how they 
> did just that in C.
>
>
> (Hopefully you get where I'm going with this and haven't been 
> pressured by legal to not respond. I know talking about this sort of 
> thing is unpleasant.)
>
>
> My understanding is that, in order to replicate what the blog does 
> using Project Panama exclusively, the lower level("unsafe") API must 
> be used since you cannot otherwise create a Pointer to the functions 
> out of an address. Looking through the high level java.foreign API 
> doesn't show anything obvious, anyway. This can only, from my 
> understanding, be done with a lower level API.
>
>
> Is this accurate?
>
>
> [1] 
> https://web.archive.org/web/20180221193221/https://1vwjbxf1wko0yhnr.wordpress.com/2015/08/10/overclocking-tools-for-nvidia-gpus-suck-i-made-my-own/
>