Re: [RFC PATCH] grep: allow for run time disabling of JIT in PCRE

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jul 29 2019, Carlo Marcelo Arenas Belón wrote:

> PCRE1 allowed for a compile time flag to disable JIT, but PCRE2 never
> had one, forcing the use of JIT if -P was requested.

What's that PCRE1 compile-time flag?

> After ed0479ce3d (Merge branch 'ab/no-kwset' into next, 2019-07-15)
> the PCRE2 engine will be used more broadly and therefore adding this
> knob will give users a fallback for situations like the one observed
> in OpenBSD with a JIT enabled PCRE2, because of W^X restrictions:
>
>   $ git grep 'foo bar'
>   fatal: Couldn't JIT the PCRE2 pattern 'foo bar', got '-48'
>   $ git grep -G 'foo bar'
>   fatal: Couldn't JIT the PCRE2 pattern 'foo bar', got '-48'
>   $ git grep -E 'foo bar'
>   fatal: Couldn't JIT the PCRE2 pattern 'foo bar', got '-48'
>   $ git grep -F 'foo bar'
>   fatal: Couldn't JIT the PCRE2 pattern 'foo bar', got '-48'

Yeah that obviously sucks more with ab/no-kwset, but that seems like a
case where -P would have been completely broken before, and therefore I
can't imagine the package ever passed "make test". Or is W^X also
exposed as some run-time option on OpenBSD?

I.e. aside from the merits of such a setting in general these examples
seem like just working around something that should be fixed at make
all/test time, or maybe I'm missing something.

To the extent that we'd want to make this sort of thing configurable, I
wonder if a continuation of my (*NO_JIT) patch isn't better, i.e. just
adding the ability to configure some string we'd inject at the start of
every pattern.

That would allow for setting any other number of options in
pcre2syntax(3) without us needing to carry config for each one,
e.g. (*LIMIT_HEAP=d), (*LIMIT_DEPTH=d) etc. It does present a larger
foot-gun surface though...




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux