search

lkrg-org / lkrg

Linux Kernel Runtime Guard
https://lkrg.org
Other
403 stars 72 forks source link

LKRG: FATAL: Can't find 'tracepoints_mutex' #334

Closed Evolto2019 closed 1 month ago

Evolto2019 commented 2 months ago

LKRG fails to start after commit ee41d815990cd99f9f760790845e72a532fcf030 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 commented 2 months ago

@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 commented 2 months ago

@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 commented 2 months ago

@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 commented 2 months ago

@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 commented 2 months ago

@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 commented 1 month ago

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