On Mon, Dec 10 2018, brian m. carlson 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.
>
> Both versions of PCRE map pages both write and executable at the same
> time, which is presumably where things go wrong. I assume it can be
> fixed, but whether that's easy in the context of PCRE, I wouldn't know.
>
>> Are we mixing a condition where one some OS's or OS versions this just
>> won't work at all, and thus maybe should be something turned on in
>> config.mak.uname, v.s. e.g. SELinux where presumably it'll dynamically
>> change.
>
> Considering that some Linux users use PaX kernels with standard
> distributions and that most BSD kernels can be custom-compiled with a
> variety of options enabled or disabled, I think this is something we
> should detect dynamically.
Right. I'm asking whether we're mixing up cases where it can always be
detected at compile-time on some systems v.s. cases where it'll
potentially change at runtime.
>> I'm inclined to suggest that we should have another ifdef here for "if
>> JIT fails I'd like it to die", so that e.g. packages I build (for
>> internal use) don't silently slow down in the future, only for me to
>> find some months later that someone enabled an overzealous SELinux
>> policy and we swept this under the rug.
>
> My view is that JIT is a nice performance optimization, but it's
> optional. I honestly don't think it should even be exposed through the
> API: if it works, then things are faster, and if it doesn't, then
> they're not. I don't see the value in an option for causing things to be
> broken if someone improves the security of the system.
For many users that's definitely the case, but for others that's like
saying a RDBMS is still going to be functional if the "ORDER BY"
function degrades to bubblesort. The JIT improves performance my
multi-hundred percents sometimes, so some users (e.g. me) rely on that
not being silently degraded.
So I'm wondering if we can have something like:
if (!jit)
if (must_have_jit)
BUG(...); // Like currently
else
fallback(); // new behavior
