RFR: 8254231: Implementation of Foreign Linker API (Incubator) [v15]
David Holmes
david.holmes at oracle.com
Mon Nov 9 13:51:03 UTC 2020
Hi Jorn,
On 9/11/2020 9:57 pm, Jorn Vernee wrote:
> On Mon, 9 Nov 2020 03:29:05 GMT, David Holmes <dholmes at openjdk.org> wrote:
>
>> src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 99:
>>
>>> 97: if (thread == NULL) {
>>> 98: JavaVM_ *vm = (JavaVM *)(&main_vm);
>>> 99: vm -> functions -> AttachCurrentThreadAsDaemon(vm, &p_env, NULL);
>>
>> Style nit: don't put spaces around `->` operator.
>>
>> What is the context for this being called? It looks highly suspicious to just attach the current thread to the VM this way.
>
> The context is a thread that is spawned by native code doing an upcall. We need to attach the thread to the VM first in that case. Normally this would be handled by the calling code, but in our case the calling code doesn't know it's calling into Java.
Apologies that I don't have enough knowledge of this feature to
understand the context. Shouldn't you then detach it again afterwards?
Otherwise when will it detach? If you don't detach you will get a memory
leak.
>> src/java.base/share/classes/jdk/internal/invoke/NativeEntryPoint.java line 63:
>>
>>> 61: }
>>> 62:
>>> 63: public static NativeEntryPoint make(long addr, String name, ABIDescriptorProxy abi, VMStorageProxy[] argMoves, VMStorageProxy[] returnMoves,
>>
>> Where is name validation performed, to ensure the named native method is in fact legal and not trying to provide backdoor access to native code that should be encapsulated and protected?
>
> The name is just used as debugging information (in e.g. CallNativeNode::dump_spec), we are not looking it up. The address that is passed there is the actual function target.
Okay.
Thanks,
David
-----
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/634
>
More information about the security-dev
mailing list