On Fri, 12 Apr 2024 15:26:03 GMT, Andrew Haley <a...@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
