[PATCH 0/2] Deal with G_REGEX_OPTIMIZE pitfalls

Peter Krempa via Devel posted 2 patches 4 days, 23 hours ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/libvirt tags/patchew/cover.1779722846.git.pkrempa@redhat.com
build-aux/syntax-check.mk | 13 +++++++++++++
src/conf/domain_event.c   |  2 +-
src/util/vircommand.c     |  2 +-
src/util/virlog.c         |  2 +-
4 files changed, 16 insertions(+), 3 deletions(-)
[PATCH 0/2] Deal with G_REGEX_OPTIMIZE pitfalls
Posted by Peter Krempa via Devel 4 days, 23 hours ago
G_REGEX_OPTIMIZE invokes PCRE's JIT optimizer for regexes which requires
writable executable memory. This clashes with the 'execmem' SELinux
permission which we don't really want to grant to any of the virt
daemons.

Since all uses of G_REGEX_OPTIMIZE are on code paths unlikely to hit the
~3x performance penalty of using interpeted evaluation of the regex
rather than the JIT'd one we can simply remove the optimization from the
rest of the calls. (Only 3 of 10 used it).

Patch 2 is optional; selinux can simply ban 'execmem' and mark it as
'dontaudit'. glib will fall back to the interpreter.

The patches are based on a discussion which I've summarized in:
https://redhat.atlassian.net/browse/RHEL-44901

Peter Krempa (2):
  syntax-check: Add warning about implications of G_REGEX_OPTIMIZE
  Avoid use of glib's G_REGEX_OPTIMIZE flag

 build-aux/syntax-check.mk | 13 +++++++++++++
 src/conf/domain_event.c   |  2 +-
 src/util/vircommand.c     |  2 +-
 src/util/virlog.c         |  2 +-
 4 files changed, 16 insertions(+), 3 deletions(-)

-- 
2.54.0
Re: [PATCH 0/2] Deal with G_REGEX_OPTIMIZE pitfalls
Posted by Ján Tomko via Devel 4 days, 5 hours ago
On a Monday in 2026, Peter Krempa via Devel wrote:
>G_REGEX_OPTIMIZE invokes PCRE's JIT optimizer for regexes which requires
>writable executable memory. This clashes with the 'execmem' SELinux
>permission which we don't really want to grant to any of the virt
>daemons.
>
>Since all uses of G_REGEX_OPTIMIZE are on code paths unlikely to hit the
>~3x performance penalty of using interpeted evaluation of the regex
>rather than the JIT'd one we can simply remove the optimization from the
>rest of the calls. (Only 3 of 10 used it).
>
>Patch 2 is optional; selinux can simply ban 'execmem' and mark it as
>'dontaudit'. glib will fall back to the interpreter.
>
>The patches are based on a discussion which I've summarized in:
>https://redhat.atlassian.net/browse/RHEL-44901
>
>Peter Krempa (2):
>  syntax-check: Add warning about implications of G_REGEX_OPTIMIZE
>  Avoid use of glib's G_REGEX_OPTIMIZE flag
>

Reviewed-by: Ján Tomko <jtomko@redhat.com>

Jano