[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: PAX mprotect and JIT
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
The test case mprotect_pax in src/tests/lib/libc/sys/t_mprotect.c tried the
latter with this function:
paxset(int global, int enabled)
size_t len = sizeof(int);
rv = sysctlbyname("security.pax.mprotect.global",
NULL, NULL, &global, len);
if (rv != 0)
rv = sysctlbyname("security.pax.mprotect.enabled",
NULL, NULL, &enabled, len);
if (rv != 0)
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.
Main Index |
Thread Index |