RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]

Anton Kozlov akozlov at openjdk.java.net
Wed Feb 3 20:11:50 UTC 2021


On Tue, 26 Jan 2021 12:50:22 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Yes, that's why I thought it should be added to the classes ThreadInVMfromNative, etc like:
>> class ThreadInVMfromNative : public ThreadStateTransition {
>>   ResetNoHandleMark __rnhm;
>> 
>> We can look at it with cleaning up the thread transitions RFE or as a follow-on.  If every line of ThreadInVMfromNative has to have one of these   Thread::WXWriteVerifier __wx_write;     people are going to miss them when adding the former.
>
> Not every ThreadInVMfromNative needs this, for example JIT goes to Native state without changing of W^X state. But from some experience of maintaining this patch, I actually had a duty to add missing W^X transitions after assert failures. A possible solution is actually to make W^X transition a part of ThreadInVMfromNative (and similar), but controlled by an optional constructor parameter with possible values "do exec->write", "verify write"...;. So in a common case ThreadInVMfromNative would implicitly do the transition and still would allow something uncommon like verification of the state for the JIT. I have to think about this.

I've dropped this transition here and in similar places after state tracking always available. As a benefit, there are few places really using the setter and all of them are tied to VM_ENTRY macro or similar one. I expect we don't need to do W^X management near every java thread state change.

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

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



More information about the security-dev mailing list