[pcre-dev] [Bug 2626] New: RFC: support for W^X executable p…

Top Page

Reply to this message
Author: admin
Date:  
To: pcre-dev
New-Topics: [pcre-dev] [Bug 2626] support for W^X executable pages with JIT
Subject: [pcre-dev] [Bug 2626] New: RFC: support for W^X executable pages with JIT
https://bugs.exim.org/show_bug.cgi?id=2626

            Bug ID: 2626
           Summary: RFC: support for W^X executable pages with JIT
           Product: PCRE
           Version: N/A
          Hardware: All
                OS: NetBSD
            Status: NEW
          Severity: wishlist
          Priority: medium
         Component: Code
          Assignee: ph10@???
          Reporter: carenas@???
                CC: pcre-dev@???


Created attachment 1326
--> https://bugs.exim.org/attachment.cgi?id=1326&action=edit
svn diff

Add a configure flag to allow pcre to be built without using the sljit provided
allocator pools.

Provide a custom "allocator" that provides pages where JIT code could be
compiled and executed even with PaX MPROTECT restrictions.

Will need at least NetBSD 8 (which is the oldest supported version), and can be
tested with :

$ ./configure --enable-jit --enable-nullalloc
$ make check

Only tested in NetBSD 9 (amd64), all others expected to work though but
confirmation would be appreciated.

Known Issues:
* missing cmake and manual configuration (omitted to simplify the changes
needed for this POC)
* currently conflicts with --enable-sljit-sealloc by silently overriding it
* code is ugly and not portable and could be modularized better. open to
suggestions.
* includes "unrelated" changes (ex: change in pcre2_jit_misc.c it is an
independent bug, but also a prerequisite)

Important Considerations:
* uses a lot more maps and therefore could hit system limits faster than the
alternatives. not sure how realistic it would be to have concurrently hundreds
of compiled functions though.
* should use more memory since the generated code is not packed together like
when using sljit's exec allocators, but not sure how badly it does compared
with a fragmented allocator in the long term.
* should be slower than using an allocator since every compilation does a mmap
and an munmap, but at least pcre2_jit_test doesn't show any significant change.

since the SLJIT_PROT_EXECUTABLE_ALLOCATOR has problems with fork() and this one
might not, and the original allocator fails unless the binaries that use them
had a `paxctl +m` exception added it might be worth considering this "on" by
default when --enable-sljit and the considerations had been covered.

--
You are receiving this mail because:
You are on the CC list for the bug.