RFR: 8330171: Lazy W^X switch implementation

[Sergey Nazarkin]

On Fri, 12 Apr 2024 15:26:03 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Hello Sergey.
>> W^X mode was initially forced by Apple to prevent writing to executable memory, as a security feature.
>> This change just eliminates this security feature at all, doesn't it ?
>> Basically: "want to write to Executable memory ? ok, here you go"
>
>> Hello Sergey. W^X mode was initially forced by Apple to prevent writing to executable memory, as a security feature. This change just eliminates this security feature at all, doesn't it ? Basically: "want to write to Executable memory ? ok, here you go"
> 
> Yes @VladimirKempik, you are right. No, we should not do this.
> 
> Instead, when we enter the VM we could track the current state of W^X and whenever we enter a block that needs to write into code space we would set W if needed. When we leave the VM or when we call back into Java we would set X, if needed. The cost of doing this would be small, but we'd have to find all the blocks that need to write into code space. This might be more effort than we want to make, though.
> 
> So where would be need to make the transitions to W? At a guess, whenever we start assembling something, and in all of the methods in nativeInst_aarch64.?pp, and in class Patcher. And to X, in the call stub and a few other places.
> 
> That would minimize the transitions exactly to the set of places we actually need.

Thanks @theRealAph, @VladimirKempik
> Instead, when we enter the VM we could track the current state of W^X and whenever we enter a block that needs to write into code space we would set W if needed. When we leave the VM or when we call back into Java we would set X, if needed. The cost of doing this would be small, but we'd have to find all the blocks that need to write into code space. This might be more effort than we want to make, though.

It is the way in which it is implemented in the current code.  Unfortunately, it is hardly maintainable solution that suffers from issues like [1-5].   

As I understand it, your concern is that the implementation doesn't prevent rogue from writing to the code cache with some some unsafe api? 

1. https://bugs.openjdk.org/browse/JDK-8302736
2. https://bugs.openjdk.org/browse/JDK-8327990
3. https://bugs.openjdk.org/browse/JDK-8327036
4. https://bugs.openjdk.org/browse/JDK-8304725
5. https://bugs.openjdk.org/browse/JDK-8307549

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

PR Comment: https://git.openjdk.org/jdk/pull/18762#issuecomment-2052164890