From: Mathias Krause <minipli@grsecurity.net>
To: git@vger.kernel.org
Cc: "Junio C Hamano" <gitster@pobox.com>,
"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
"Mathias Krause" <minipli@grsecurity.net>,
"Carlo Marcelo Arenas Belón" <carenas@gmail.com>
Subject: [PATCH v3] grep: fall back to interpreter if JIT memory allocation fails
Date: Tue, 31 Jan 2023 19:56:11 +0100 [thread overview]
Message-ID: <20230131185611.520311-1-minipli@grsecurity.net> (raw)
In-Reply-To: <20230127154952.485913-1-minipli@grsecurity.net>
Under Linux systems with SELinux's 'deny_execmem' or PaX's MPROTECT
enabled, the allocation of PCRE2's JIT rwx memory may be prohibited,
making pcre2_jit_compile() fail with PCRE2_ERROR_NOMEMORY (-48):
[user@fedora git]$ git grep -c PCRE2_JIT
grep.c:1
[user@fedora git]$ # Enable SELinux's W^X policy
[user@fedora git]$ sudo semanage boolean -m -1 deny_execmem
[user@fedora git]$ # JIT memory allocation fails, breaking 'git grep'
[user@fedora git]$ git grep -c PCRE2_JIT
fatal: Couldn't JIT the PCRE2 pattern 'PCRE2_JIT', got '-48'
Instead of failing hard in this case and making 'git grep' unusable on
such systems, simply fall back to interpreter mode, leading to a much
better user experience.
As having a functional PCRE2 JIT compiler is a legitimate use case for
performance reasons, we'll only do the fallback if the supposedly
available JIT is found to be non-functional by attempting to JIT compile
a very simple pattern. If this fails, JIT is deemed to be non-functional
and we do the interpreter fallback. For all other cases, i.e. the simple
pattern can be compiled but the user provided cannot, we fail hard as we
do now as the reason for the failure must be the pattern itself. To aid
users in helping themselves change the error message to include a hint
about the '(*NO_JIT)' prefix. Also clip the pattern at 64 characters to
ensure the hint will be seen by the user and not internally truncated by
the die() function.
Cc: Carlo Marcelo Arenas Belón <carenas@gmail.com>
Signed-off-by: Mathias Krause <minipli@grsecurity.net>
---
v2: https://lore.kernel.org/git/20230127154952.485913-1-minipli@grsecurity.net/
Changes in v3:
Mention the possibility to prefix a failing pattern with '(*NO_JIT)' in
case we run into the JIT's limitations, as per Junio. Also clip the
printed pattern to ensure the hint actually gets printed.
---
grep.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 48 insertions(+), 2 deletions(-)
diff --git a/grep.c b/grep.c
index 06eed694936c..c6fd44e3ec94 100644
--- a/grep.c
+++ b/grep.c
@@ -262,6 +262,31 @@ static void pcre2_free(void *pointer, MAYBE_UNUSED void *memory_data)
free(pointer);
}
+static int pcre2_jit_functional(void)
+{
+ static int jit_working = -1;
+ pcre2_code *code;
+ size_t off;
+ int err;
+
+ if (jit_working != -1)
+ return jit_working;
+
+ /*
+ * Try to JIT compile a simple pattern to probe if the JIT is
+ * working in general. It might fail for systems where creating
+ * memory mappings for runtime code generation is restricted.
+ */
+ code = pcre2_compile((PCRE2_SPTR)".", 1, 0, &err, &off, NULL);
+ if (!code)
+ return 0;
+
+ jit_working = pcre2_jit_compile(code, PCRE2_JIT_COMPLETE) == 0;
+ pcre2_code_free(code);
+
+ return jit_working;
+}
+
static void compile_pcre2_pattern(struct grep_pat *p, const struct grep_opt *opt)
{
int error;
@@ -317,8 +342,29 @@ static void compile_pcre2_pattern(struct grep_pat *p, const struct grep_opt *opt
pcre2_config(PCRE2_CONFIG_JIT, &p->pcre2_jit_on);
if (p->pcre2_jit_on) {
jitret = pcre2_jit_compile(p->pcre2_pattern, PCRE2_JIT_COMPLETE);
- if (jitret)
- die("Couldn't JIT the PCRE2 pattern '%s', got '%d'\n", p->pattern, jitret);
+ if (jitret == PCRE2_ERROR_NOMEMORY && !pcre2_jit_functional()) {
+ /*
+ * Even though pcre2_config(PCRE2_CONFIG_JIT, ...)
+ * indicated JIT support, the library might still
+ * fail to generate JIT code for various reasons,
+ * e.g. when SELinux's 'deny_execmem' or PaX's
+ * MPROTECT prevent creating W|X memory mappings.
+ *
+ * Instead of faling hard, fall back to interpreter
+ * mode, just as if the pattern was prefixed with
+ * '(*NO_JIT)'.
+ */
+ p->pcre2_jit_on = 0;
+ return;
+ } else if (jitret) {
+ int need_clip = p->patternlen > 64;
+ int clip_len = need_clip ? 64 : p->patternlen;
+ die("Couldn't JIT the PCRE2 pattern '%.*s'%s, got '%d'%s",
+ clip_len, p->pattern, need_clip ? "..." : "", jitret,
+ pcre2_jit_functional()
+ ? "\nPerhaps prefix (*NO_JIT) to your pattern?"
+ : "");
+ }
/*
* The pcre2_config(PCRE2_CONFIG_JIT, ...) call just
--
2.39.1
next prev parent reply other threads:[~2023-01-31 18:56 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-16 12:15 [PATCH] grep: fall back to interpreter mode if JIT fails Mathias Krause
2022-12-16 16:12 ` Ævar Arnfjörð Bjarmason
2022-12-16 19:26 ` Mathias Krause
2022-12-16 23:09 ` Junio C Hamano
2022-12-17 2:50 ` Carlo Arenas
2022-12-19 9:00 ` Ævar Arnfjörð Bjarmason
2022-12-20 19:29 ` Mathias Krause
2022-12-20 21:11 ` Ævar Arnfjörð Bjarmason
2023-01-18 14:22 ` Mathias Krause
2023-01-18 15:44 ` Ævar Arnfjörð Bjarmason
2023-01-19 9:19 ` Mathias Krause
2022-12-16 22:52 ` Junio C Hamano
2022-12-20 20:40 ` Mathias Krause
2023-01-27 15:49 ` [PATCH v2] grep: fall back to interpreter if JIT memory allocation fails Mathias Krause
2023-01-27 16:34 ` Junio C Hamano
2023-01-27 17:39 ` Junio C Hamano
2023-01-27 18:46 ` Junio C Hamano
2023-01-29 13:37 ` Mathias Krause
2023-01-29 13:36 ` Mathias Krause
2023-01-29 17:15 ` Junio C Hamano
2023-01-30 10:56 ` Ævar Arnfjörð Bjarmason
2023-01-30 18:49 ` Junio C Hamano
2023-01-31 8:34 ` Ævar Arnfjörð Bjarmason
2023-01-30 11:08 ` Mathias Krause
2023-01-30 18:54 ` Junio C Hamano
2023-01-30 20:08 ` Junio C Hamano
2023-01-30 21:21 ` Junio C Hamano
2023-01-30 22:30 ` Ramsay Jones
2023-01-30 23:27 ` Junio C Hamano
2023-01-31 7:48 ` Mathias Krause
2023-01-31 16:41 ` Junio C Hamano
2023-01-31 18:34 ` Mathias Krause
2023-01-31 7:30 ` Mathias Krause
2023-01-29 12:28 ` Mathias Krause
2023-01-31 18:56 ` Mathias Krause [this message]
2023-01-31 21:05 ` [PATCH v3] " Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230131185611.520311-1-minipli@grsecurity.net \
--to=minipli@grsecurity.net \
--cc=avarab@gmail.com \
--cc=carenas@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).