Dear Maintainer,

Currently, pcre2 is built in a mode where its JIT uses memory mappings
that are writable and executable at the same time, which is unsafe and
unnecessary.

Instead, it is possible to enable a different allocator that uses
separate mappings for the same allocation, one with read/write and one
with read/executable mappings, the placement of which is randomized in
the process's virtual address space, making abuse much harder.

Please consider applying the change below to switch all 64-bit
architectures to the alternative allocator. 32-bit architectures are far
more likely to run out of virtual address space, so there, we should
probably stick with the original allocator.
--- a/debian/rules
+++ b/debian/rules
@@ -15,6 +15,10 @@ deb_maint_conf_args = --enable-pcre2-16 --enable-pcre2-32 --disable-pcre2grep-ca
 #enable JIT only on architectures that support it (see pcre2jit.3)
 ifneq ($(filter i386 amd64 armel armhf mips mipsel mips64el powerpc sparc arm64 ppc64 ppc64el s390x, $(DEB_HOST_ARCH)),)
 deb_maint_conf_args +=--enable-jit
+ifneq ($(DEB_HOST_ARCH_BITS),32)
+#the W^X allocator is safer but uses more virtual address space, so enable it on 64-bit arches only
+deb_maint_conf_args +=--enable-jit-sealloc
+endif

tags + moreinfo
quit

Hi,

Thanks for bringing this up. I'm not immediately sure how safe and
sensible this would be to deploy.

It's noted as experimental in configure.ac:

# Handle --enable-jit-sealloc (disabled by default and only experimental)

And, if I've followed the code through the build flags, it has the
effect of setting SLJIT_PROT_EXECUTABLE_ALLOCATOR to 1; which is
commented thus:

/* When SLJIT_PROT_EXECUTABLE_ALLOCATOR is enabled SLJIT uses
    an allocator which does not set writable and executable
    permission flags at the same time.
    Instead, it creates a shared memory segment (usually backed by a file)
    and maps it twice, with different permissions, depending on the use
    case.
    The trade-off is increased use of virtual memory, incompatibility with
    fork(), and some possible additional security risks by the use of
    publicly accessible files for the generated code. */

[it also talks about SELinux in the docs, so I'm not immediately clear
how this relates to that and/or systems where SELinux isn't in use]

...so my feeling is this may not be an obviously good change to make
distribution-wide...

Regards,

Matthew

FYI,

systemd's MemoryDenyWriteExecute=yes breaks "git grep" because of pcre2jit.

An easy test command is something like this:

    $ journalctl --user -fn0 &   # so you see the error
    $ systemd-run --property=MemoryDenyWriteExecute=yes --user git -C /srv/vcs/kb grep -Fwi mutt

Software authors that use pcre2 can opt to not use jit (e.g. by
specifying PCRE2_NO_JIT in the arguments to pcre2_match, not calling
pcre2_jit_compile()). So I think if you wanted git to not use PCRE2's
JIT, the git authors would be the people to ask for that feature.

You could ask the PCRE2 authors to consider an environment variable to
disable JIT at runtime, but I suspect they'd say this was the sort of
thing that applications using PCRE2 should do instead.

Regards,

Matthew