LKRG: FATAL: Can't find 'tracepoints_mutex'

[Evolto2019]

LKRG fails to start after commit ee41d81 and gives error message:

LKRG: ALIVE: Loading LKRG
LKRG: ISSUE: Can't enforce SELinux validation (CONFIG_GCC_PLUGIN_RANDSTRUCT detected)
LKRG: ISSUE: [kretprobe] register_kretprobe() for <ovl_dentry_is_whiteout> failed! [err=-2]
LKRG: ISSUE: Can't hook 'ovl_dentry_is_whiteout'. This is expected when OverlayFS is not used.
LKRG: FATAL: Can't find 'tracepoints_mutex'
LKRG: FATAL: Can't create database
LKRG: DYING: Not loading LKRG (initialization failed)
p_exploit_detection_exit+0x2e/0xa0 [lkrg]
init_module+0x408/0x2000 [lkrg]
p_offload_cache_delete+0x11/0x40 [lkrg]
init_module+0x418/0x2000 [lkrg]
printk: legacy console [lkrg0] disabled

I have no idea what "tracepoints_mutex" is, can it be relevant to some hardened kconfig options? I'm currently on Linux hardened 6.8.6.

[solardiz]

@Evolto2019 Thank you for reporting this. My best guess is you don't have CONFIG_TRACEPOINTS enabled. Can you please check whether this is the case? As I can see, this option is auto-enabled (or not) depending on certain other options; it is not configurable directly.

@Adam-pi3 Would it be safe to skip locking this mutex when it doesn't exist? If so, do you prefer we check at runtime (make failure of this symbol lookup non-fatal, maybe an ISSUE or even a normally hidden debugging message?) or at build time (check for CONFIG_TRACEPOINTS)?

[Evolto2019]

@solardiz Thanks for the reply. I've done a quick look at my kconfig and didn't find CONFIG_TRACEPOINTS in it, so I guess it's set to the default value? Put my complete kconfig here incase it's needed.
config.txt

[solardiz]

@Evolto2019 Thank you. This should be an easy fix for us, but I'll wait for Adam's comments on how to fix it.

[Adam-pi3]

@solardiz yes, it looks correct. Sounds like CONFIG_TRACEPOINT guards should be added. However, tracepoints_mutex is defined as static and kernel hardening which @Evolto2019 is using may change the symbol name - a bit unrelated problem but just FYI.

[solardiz]

@Adam-pi3 My understanding is that compiler optimizations could mangle the name (and much more) of a static function, but tracepoints_mutex is not a function.

[solardiz]

@Evolto2019 We think this issue is fixed - can you please test and confirm? Thank you!