RFR: 8262952: [macos_aarch64] os::commit_memory failure
Thomas Stuefe
stuefe at openjdk.java.net
Tue May 11 13:36:03 UTC 2021
On Mon, 10 May 2021 15:52:40 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:
>> src/hotspot/os/bsd/os_bsd.cpp line 1708:
>>
>>> 1706: // On macOS aarch64 MAP_JIT is required if we want to commit an executable chunk
>>> 1707: // later, so always reserve executable memory right from the start
>>> 1708: MACOS_AARCH64_ONLY(| MAP_JIT);
>>
>> Is this the right way to do it? Where do we ever map memory we want to use for code generation, but not ask for exec permission? Is that a bug?
>
> Inside the hotspot VM code we seem to be doing the right thing, however, in the test, i.e. `test/hotspot/gtest/runtime/test_os.cpp` we ask for regular memory, then try to commit a chunk with elevated exec privileges, which seems to work on all other platforms, except aarch64 macOS.
>
> The alternative, would be to fix the test in question, but since this scenario works fine on all the other platforms, I figured the proposed way to handle it in the VM would be the preferable way to fix it, so future test writers do not need to know this particular platform behavior difference and risk getting it wrong again.
Hi @gerard-ziemski,
please fix the test instead. This would be a security issue, especially since the locations of some of our mappings are very predictable (eg CDS archive).
If this is about the "multi-release" test in test_os.cpp (377ff), just disable the exec flag there. I use alternating exec
flags to prevent the kernel from folding neighboring mappings, but actually that part is rather linux specific. Arguably we may even completely exclude the test, like I do for AIX already. Its important for Windows, somewhat less important for Linux, and covers other platforms only for completeness sake.
Wrt to MAP_JIT , what we do now is the result of long discussions: https://git.openjdk.java.net/jdk/pull/294.
Cheers, Thomas
-------------
PR: https://git.openjdk.java.net/jdk/pull/3865
More information about the hotspot-runtime-dev
mailing list