Support for JIT option for PCRE2 by martinhsv · Pull Request #2840 · owasp-modsecurity/ModSecurity (original) (raw)

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Conversation4 Commits1 Checks0 Files changed

Conversation

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters

[ Show hidden characters]({{ revealButtonHref }})

martinhsv

As with legacy PCRE, you need to include --enable-pcre-jit during the configure step to use this functionality.

@martinhsv

@S0obi

Hey @martinhsv, thanks for this PR. Are you advising to use this flag in Modsec installations ? Did you notice any interesting gains in term of performance ? Any downsides ? Thanks in advance.

@airween

Did you notice any interesting gains in term of performance ?

There is a small project which emulates the behavior of @rx operator, both for mod_security2 and libmodsecurity3: msc_retest (please note, that this link points to a not-merged separated branch).

With this, you can try the performance (actually only in case of libmodsecurity3 - but I'm sure you will be able to compare the performance, and want to use the flag 😃). For more information see the attached README, or this article.

@martinhsv

Hi @S0obi ,

I did not attempt to quantify the performance gains here -- much depends on the regular expressions that are being used and the strings that are matched against them. However, most installations would see some benefit (or at worst no performance reduction) in using the jit option.

(One exception to this could be if most of the regular expressions being used for matching are generated at runtime (for example by including "%{}" variables in the pattern). Since the extra up-front processing would not happen only once at startup, there is at least a chance that the any efficiency improvement during the match might be exceeded by the compile costs.)

@martinhsv

I am likely to merge this is soon, as is.

One extra thing to note is that actually making use of the PCRE2 JIT functionality depends not only on setting this option during the ModSecurity configure step, but that PCRE2 itself was built with the JIT option specified (it is not the default).

If you specify --with-pcre2 --enable-pcre-jit while configuring ModSecurity but your build of PCRE2 does not support JIT, nothing bad will happen. Processing in ModSecurity will fall back to non-JIT matching.

But, ModSecurity's configure step will not currently warn you that what you have asked for is not available. That would be a good enhancement that I will try to take a look at.

Labels

2.x

Related to ModSecurity version 2.x