On Sun, Feb 26, 2017 at 10:34:12PM +0100, Martin Husemann wrote: > On Sun, Feb 26, 2017 at 02:09:08PM +0100, Joerg Sonnenberger wrote: > > The mremap() dance is only desirable for multi-threaded JIT. If you > > compile a module at a time before making it visible, just a plain > > mprotect is enough. > > I would prefer to not allow toggling back and forth via mprotect() at all.
Picking up an old thread, as I stumbled into something related yesterday: 1) We do not have a method for a process to query whether pax mprotect is active for itself. This needs to be fixed. 2) We do not have a method for a process to turn on mprotect for itself. I am not sure this is needed, but it is at least usefull for testing purposes. The test case mprotect_pax in src/tests/lib/libc/sys/t_mprotect.c tried the latter with this function: static bool paxset(int global, int enabled) { size_t len = sizeof(int); int rv; rv = sysctlbyname("security.pax.mprotect.global", NULL, NULL, &global, len); if (rv != 0) return false; rv = sysctlbyname("security.pax.mprotect.enabled", NULL, NULL, &enabled, len); if (rv != 0) return false; return true; } but there are two issues with this (pointed out by Chuck): tests should not modify global system state like this, but even worse: the sysctl variable will only affect new processes, not the already running ones. So this test case always failed on system where mprotect was not enabled globaly. On some architectures this is not possible, but we could compile it special (example: on sparc64 it would have to be static) and mark it with paxctl - this would require a method to test "am I mprotected?" reliably. Or we could allow it to toggle mprotect on for itself only. I guess the query function would be helpfull for JIT as well. Martin