RFR: 8282475: SafeFetch should not rely on existence of Thread::current [v6]

[Anton Kozlov]

On Thu, 10 Mar 2022 05:52:48 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Why don't we just switch it on once, for a thread that conceivably may call into generated code, and be done with? Why is this fine granular switching even needed? I find it difficult to imagine an attack vector that exploits having this always enabled for a thread. After all, we have to mark code cache with MAP_JIT already, so it is not like we can execute arbitrary memory ranges.

A java thread executes the code (interpreter, JIT) and changes the code (e.g. it could make a nmethod non entrant, change inline cache). Code modifications are done in VM (runtime) call. So WX state is tied to java thread state. The WX management is done more to satisfy the platform requirement, than to make the system more secure.

> Related to that, how much does this call cost? Is this a runtime call into the pthread library or does it get inlined somehow? Because things like SafeFetch are trimmed to be super cheap if the memory can be accessed. Doing a pthread call on every invocation may throw off the cost benefit ratio.

SafeFetch is much more expensive compared the direct memory access. So I assume it's used only when the real chance exists the access may fail, and the average cost of SafeFetch is much higher than the best case. 

Yes, WX management is offered via a pthread function call. I haven't investigated if the native compiler can inline the call. The WX management itself considerably cheap https://github.com/openjdk/jdk/pull/2200#issuecomment-773382787.

> Why and where do we need nesting? This would be so much easier if we could just not care.

We swtich the state to WXWrite at the entry in VM call, but a VM call may do another VM call. E.g. a runtime VM calls the JNI GetLongField. So GetLongField could be called from a code executing in Java (WXExec) and VM (WXWrite) states, the WX state should be restored back on leaving JNI function. The original state is tracked in Thread.

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

PR: https://git.openjdk.java.net/jdk/pull/7727