[foreign-memaccess+abi] RFR: 8274602: Generalize UpcallStub into NativeSymbol

[Jorn Vernee]

On Tue, 5 Oct 2021 12:04:23 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/NativeSymbol.java line 46:
>> 
>>> 44:      * Restricted methods are unsafe, and, if used incorrectly, their use might crash
>>> 45:      * the JVM or, worse, silently result in memory corruption. Thus, clients should refrain from depending on
>>> 46:      * restricted methods, and use safe and supported functionalities, where possible.
>> 
>> Why is this restricted?
>
> because you can create a native symbol out of an arbitrary address (e.g. MemoryAddress.ofLong), which then, if passed to a downcall method handle, will cause havocs. That said, true that, at the moment you can pass Addressable to a downcall method handle - but maybe that's the issue? E.g. downcall method handle needs to take in a NativeSymbol? That way, all native symbols created by our APIs are known to be safe (upcall and symbol lookup) - but the user is still free to create custom symbols - although these latter would be restricted. Makes sense?

That makes sense, but we are already covered there I think because creating downcall handles is a restricted operation.

Compare it to `MemoryAddress.ofLong` which is also non-restricted: it's fine to make non-dereferencable addresses, because in order to dereference them, we need to go through a restricted API. This case seems kind of similar.

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/589