On Sun, Dec 9, 2018 at 4:42 PM brian m. carlson <sandals@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Mon, Dec 10, 2018 at 12:51:01AM +0100, Ævar Arnfjörð Bjarmason wrote: > > Obviously this & what you have in 2/2 needs to be fixed in some way. > > > > Is the issue on SELinux, OpenBSD, NetBSD etc. *how* PCRE is creating the > > the JIT'd code? I.e. presumably Google Chrome's JIT engine, Java JIT and > > the like work on those setup, or not? I.e. is this something upstream > > can/is likely to fix eventually? > > From the cover letter (but without testing), it seems like it would > probably be fine to first map the pages read-write to write the code and > then, once that's done, to map them read-executable. I know JIT > compilation does work on the BSDs, so presumably that's the technique to > make it do so. and that has been implemented (sljitProtExecAllocator.c) as part of the work triggered by the bug I linked about [1], deep inside sljit (which is what pcre uses for JIT) the code AS-IS wouldn't compile for the BSD[2] but that is easy to fix and sure works as expected but I am under the impression that is not something that can be considered as a solution as explained by the open issues described with crashes after a fork() note that changing the map from read-write to executable will be prevented by the same policy so you have to create 2 maps (and therefore a backing file) and I don't think there is a way to solve that in a foolproof way in a library which is why I mentioned more work might be needed to define the right interfaces so it can be solved by the application, and that is unlikely to happen with the old library. Carlo [1] https://bugs.exim.org/show_bug.cgi?id=1749 [2] https://bugs.exim.org/show_bug.cgi?id=2155
