On Mon, Jul 29, 2019 at 1:55 AM Ævar Arnfjörð Bjarmason
<avarab@xxxxxxxxx> wrote:
>
> 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?
NO_LIBPCRE1_JIT at GIT compile time (regardless of JIT support in the
PCRE1 library you are using)
> > 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?
ironically, you could use PCRE1 since that is not using the JIT fast
path and therefore will fallback automatically to the interpreter
there is also a convoluted way to make your binary work by moving
it into a mount point that has been specially exempted from that W^X
restriction.
> 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.
1) before you could just avoid using -P and still be able to grep
2) there is no way to tell PCRE2 to get out of the way even if you are
not using -P
you are right though that this is not a new problem and was reported
before with patches and the last comment saying a configuration
should be provided.
> 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.
looking at the number of lines of code, it would seem the configuration
approach is simpler.
> 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...
the parameters I suspect users might need are not really accessible through
that (ex: jit stacksize).
it is important to note that currently we are not preventing any user to use
those flags themselves in their patterns either.
Carlo
