Re: PAX mprotect and JIT

[Martin Husemann <martin%duskware.de@localhost>]

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