Add JIT support for PCRE2

[wfjsw]

Added JIT to PCRE2.

I didn't thoroughly investigate the lifetime of the Regex class. The lifetime of the JIT result is attached to it.

Also it is worth noticing that PCRE2 is not following the pcre_malloc and pcre_free conventions, though I wonder what it will add if the allocation is scoped to requests.

[airween]

Just my 2c question: why does it need the own stack handling?

I do not find the article now, where the author wrote unless there is a very compelling reason, you don't need to use pcre_jit_stack_create().

Few months ago I've started to play with PCRE2 JIT implementation - you can find it here. In performance, there isn't any difference between controlling own stack with huge memory like this, or without own stack.

I also checked Nginx, it also uses pcre2 JIT without own stack.

[wfjsw]

It is actually a copy-pasta from https://www.pcre.org/current/doc/html/pcre2jit.html#SEC10
I don't know if there is any penalty doing so, and I'm fine removing this.

[wfjsw]

Tried without PCRE2 jit stack and the memory usage dropped by 50%. That's nice.

I do worry about situations like https://www.mail-archive.com/[email protected]/msg05763.html

It depends on the rules, though.

[martinhsv]

The main thing I would be concerned about here is the jit stack limit issue.

I don't have an opinion on whether the default of 32KB on the machine stack is large enough for normal (non-attack) use cases. But I can almost guarantee that either an attacker or a researcher will be able to breach that limit without using particularly excessive inputs (I'm thinking of some of the more complex CRS rules ).

The problem is that we are not handling this error scenario. PCRE2_ERROR_JIT_STACKLIMIT can effectively be treated the same as a simple 'no match' result -- which makes for a bypass opportunity.

(This new need overlaps with proposed per-match PCRE limits in #2736 , which I'll have to review soon.)

[martinhsv]

The other possible alternative if PCRE2_ERROR_JIT_STACKLIMIT in encountered, is to retry the match using regular (non-JIT) matching.

[FireBurn]

I've just tried this PR locally and I get the following error:

utils/regex.cc: In member function 'int modsecurity::Utils::Regex::search(const string&, modsecurity::Utils::SMatch*) const':
utils/regex.cc:294:24: error: 'rc' was not declared in this scope
     if (m_pcje != 0 || rc == PCRE2_ERROR_JIT_STACKLIMIT) {
                        ^~
utils/regex.cc:294:24: note: suggested alternative: 'rcmd'
     if (m_pcje != 0 || rc == PCRE2_ERROR_JIT_STACKLIMIT) {
                        ^~
                        rcmd

Adding an "int rc;" fixes things

[wfjsw]

Ah my fault

[martinhsv]

The current version looks ok. Thanks all for the various contributions. I'll plan to merge this.

[martinhsv]

Hi @wfjsw ,

cppcheck is complaining that:

warning: src/operators/verify_cc.h,39,warning,uninitMemberVar,Member variable 'VerifyCC::m_pcje' is not initialized in the constructor.

The tool is correct. Unlike with the Regex class, the normal assignment to m_pcje occurs in the init() function rather than in the constructor.

Do you want to make that amendment to the VerifyCC class? (An initial value of PCRE2_ERROR_JIT_BADOPTION might be appropriate.)

[martinhsv]

Unfortunately, it's still failing cppcheck ...

2022-12-11T21:07:44.1294490Z warning: src/utils/regex.cc,127,warning,uninitvar,Uninitialized variable: rc
2022-12-11T21:07:44.1295630Z warning: src/utils/regex.cc,175,warning,uninitvar,Uninitialized variable: rc
2022-12-11T21:07:44.1296350Z warning: src/utils/regex.cc,294,warning,uninitvar,Uninitialized variable: ret
2022-12-11T21:07:44.1296950Z warning: src/utils/regex.cc,327,warning,uninitvar,Uninitialized variable: rc

Don't worry about it. I can commit as-is and then fix it up.