https://bugs.exim.org/show_bug.cgi?id=1749
--- Comment #37 from Petr Pisar <ppi...@redhat.com> ---
(In reply to Zoltan Herczeg from comment #36)
> Landed another big patch which adds allocator support for other CPUs except
> Tile-GX. The good (bad) news is that on-the-fly code modifications are
> available again regardless of allocator. However it is not tested on real
> hardware only in qemu, which seems have issues with dual mapped files. Would
> be good to test the JIT compiler regression tests on real hardware as well.
>
A build the SVN code and run tests without and with
-DSLJIT_PROT_EXECUTABLE_ALLOCATOR=1 on with JIT enabled where supported on
these platforms without any failure:
aarch64
i686
ppc
ppc64le
ppc64
s390
s390x
x86_64
All the tests were run without SELinux enforcing.
Running the tests with SELinux enforcing W^X pages on all of the platforms
would require more time, thus I checked only on my x86_64 workstation and I can
state it works.
> > If the code checked for the error and propagated it back to the
> > pcre2_jit_compile(), applications could handle it in the same way as if JIT
> > was unavailable at all (pcre2_jit_compile() would return
> > PCRE2_ERROR_JIT_BADOPTION).
>
> I am not sure I understand the reason behind this. The allocator may open
> several 64K+ tmp files, and if some of them are not successful, why should
> we return with BADOPTION? And PCRE always falls back to interpreted mode
> regardless of error.
>
If the JIT allocator cannot open the temporary file, it will pcre2grep tool
will fail with "Error in command-line regex at offset 7: no more memory". If
the library returned BADOPTION, the tool would conclude that JIT is not
available and could continue.
You can try it with:
# chmod 01770 /tmp
$ make check
The pcre2grep tests will fail with "no more memory", fastjit pcre2test tests
will segfault and pcre2_jit_test will fail with "JIT compiler does not
support...".
While I admit running the tests with this condition is quite artificial, it's
quite common that secure-tightened daemons are not allowed to write to any file
system. Then these daemons would fail.
pcre2_jit_compile(3) reads:
The yield of the function is 0 for success, or a negative error code
otherwise. In particular, PCRE2_ERROR_JIT_BADOPTION is returned if JIT
is not supported or if an unknown bit is set in options.
I think it's more correct to return PCRE2_ERROR_JIT_BADOPTION than
PCRE2_ERROR_NOMEMORY from pcre2_jit_compile() in this case because the result
is that such system does not support JIT. Not that the system does not have
free memory. Applications tends to raise an error in case of
PCRE2_ERROR_NOMEMORY while they ignore the error in case of
PCRE2_ERROR_JIT_BADOPTION. At least this is how I would write an application
after reading the pcre2_jit_compile(3) manual.
But you can be right especially if the JIT compiler does multiple allocations
and only a subsequent allocation fails. Then probably the easiest solution is
keep the JIT code as it is and only amend pcre2_jit_compile(3) documentation
stating it is safe to ingnore pcre2_jit_compile(3) failure if the application
is not going to use JIT specific functions later.
> I also don't understand the following sentence:
>
> > The environment variable TMPDIR, if it is defined. For security reasons
> > this only happens if the program is not SUID or SGID enabled.
>
> This is again some security feature I don't understand. The echo $TMPDIR
> yields nothing on my system.
Some programs create fix-named temporary files. If an attacker can control
TMPDIR environment variable, SUID program would write to directory of
attacker's choice and the final file could coincide with a file the attacker
does not have access otherwise.
--
You are receiving this mail because:
You are on the CC list for the bug.
--
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
