On Thu, 10 Mar 2022 05:52:48 GMT, Thomas Stuefe <stu...@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

Reply via email to