https://bugs.exim.org/show_bug.cgi?id=2445
Carlo Marcelo Arenas Belón <carenas@???> changed:
What |Removed |Added
----------------------------------------------------------------------------
Hardware|x86-64 |All
OS|Linux |All
--- Comment #15 from Carlo Marcelo Arenas Belón <carenas@???> ---
(In reply to Nikita Popov from comment #14)
> simply making it "someone else's problem", rather than PCRE's.
doing this have several advantages though:
* most hardened systems have ways to add exceptions to applications that can be
used to allow the application to use JIT even in those cases
* most applications can add code to detect JIT was not usable and fallback to
use the interpreter in those cases (like PCRE2 mostly does as a user of sljit)
note that exceptions (ex: SELinux tags, can be attached to binaries but AFAIK
might not a SO that might be either loaded at runtime programmatically or
through the system's dynamic linker)
even if SELinux is extended (or has that support, which frankly I might not
know about), other similar systems from BSD will not, hence why making sure
security tagging/fallback is done at the application level is IMHO better long
term; regardless
> For example, distro PHP will generally be linked against system libpcre2,
> but PHP itself will have absolutely no knowledge of how it can obtain
> executable memory under the limitations of that particular distro.
but PHP might be able to provide an application flag/configuration that can be
used to not even attempt to use JIT or do its own check at runtime and fallback
to use the interpreter (like PCRE attempts to do now)
> What would be more useful for us at least, is if the right way was
> determined at runtime (rather than compile-time) by trying through the
> different ways that are available until one works (which right now would be
> to try an W+X mapping, then try the offseted W^X mapping with tempfile, then
> give up). Similar to the check that was recently added for whether the
> executable mapping works at all.
that is the current implementation, but we could argue (ex: in Debian) that we
should also try to use /run if SystemD is being used as init, and unless
SysVinit is used instead, where might make sense to try /dev/shm.
imagine all the logic that will be required for covering all posible
combinations of OS/init (or even libc) for all those cases.
--
You are receiving this mail because:
You are on the CC list for the bug.
