[krsi] No events generated despite BPF programs attached

[fortigate3600]

Describe the bug

The krsi plugin loads successfully and its BPF programs are attached to the kernel (verified via bpftool prog show), but no krsi_open events ever reach the Falco engine. A rule matching the bare event type evt.type = krsi_open never triggers e.g. file opens such as cat /etc/passwd. No error or warning related to KRSI, BPF attach, or LSM is logged, even at debug log level.

How to reproduce it

1. Build the krsi plugin from source (repo falcosecurity/plugins, branch main, commit 7086c69 Jun 8, 2026) and place libkrsi.so under /usr/share/falco/plugins/.

2. Configure the plugin in falco.yaml:

   plugins:
     - name: krsi
       library_path: libkrsi.so
       init_config:
         io_uring: true
         syscall: true

   And the config.d/falco.container_plugin.yaml

   load_plugins: [container, krsi]

3. Used 2 catch-all rules:

   - rule: KRSI catch all
     desc: catch any krsi_open
     condition: evt.type = krsi_open
     output: "GOT_KRSI name=%krsi.name proc=%proc.name iou=%krsi.iou_ret"
     priority: NOTICE
     source: syscall
   
   - rule: Sensitive File Access (syscall o io_uring)
     desc: >
       Opening of sensitive files detected via LSM hook (krsi).
     condition: >
       evt.type = krsi_open
       and krsi.name in (/etc/passwd)
     output: >
       File opened (file=%krsi.name flags=%krsi.flags
       iou_ret=%krsi.iou_ret proc=%proc.name cmdline=%proc.cmdline
       pid=%proc.pid user=%user.name)
     priority: WARNING
     tags: [filesystem, io_uring]

4. Run Falco with the modern eBPF probe:

   sudo falco -c /etc/falco/falco.yaml -r /tmp/krsi_custom_rule.yaml
   

5. In another terminal:

   cat /etc/passwd > /dev/null
   

Expected behaviour

The KRSI catch all rule should fire and emit a GOT_KRSI line for the krsi_open event generated by the file open.

Actual behaviour

No event is generated. Falco reports Events detected: 0 and no GOT_KRSI line appears. This holds for any condition based on evt.type = krsi_open, regardless of additional field filters.

Diagnostic evidence

The plugin is loaded and its capabilities are registered (--list-plugins):

Name: krsi
Description: Falco support for Kernel Runtime Security Instrumentation
Version: 0.2.0
Capabilities:
  - Field Extraction
  - Event Parsing
  - Async Event

The krsi field class is exposed correctly (--list krsi), including krsi.name, krsi.flags, krsi.iou_ret, etc.

The kernel has BPF LSM active:

$ cat /sys/kernel/security/lsm
lockdown,capability,landlock,yama,apparmor,bpf,ima,evm

$ grep CONFIG_BPF_LSM /boot/config-$(uname -r)
CONFIG_BPF_LSM=y

$ dmesg | grep -i lsm
LSM: initializing lsm=lockdown,capability,landlock,yama,apparmor,bpf,ima,evm
LSM support for eBPF active

Kernel lockdown is off ([none]), and Falco runs as root.

While Falco is running, the KRSI BPF programs are attached to the relevant hooks (bpftool prog show, distinct btf_id from the syscall probe):

2648: tracing  name security_file_open_x  tag 7425abb949a1d7b7  gpl  btf_id 231
2649: tracing  name io_openat2_x           tag ff9de99050c3c263  gpl  btf_id 231
2650: tracing  name io_openat2_e           tag d28433697251fda7  gpl  btf_id 231
...

So the programs are attached, but the corresponding events are not propagated to the Falco engine.

Debug-level startup output

Running with -o log_level=debug shows the plugin being loaded and the engine being opened:

$ grep -E "Loading plugin 'krsi'|Loaded event sources|Enabled event sources|Opening 'syscall'|Trying to open the right engine" /tmp/krsi_debug.log
Loading plugin 'krsi' from file /usr/share/falco/plugins/libkrsi.so
Loaded event sources: syscall
Enabled event sources: syscall
Opening 'syscall' source with modern BPF probe.
[libs]: Trying to open the right engine!

Filtering the full debug log for any KRSI-, BPF-, attach-, or error-related keyword returns only the plugin-load line, the rule-load entries, and the syscall lists (where bpf and lsm_* appear merely as names of monitored syscalls, not as plugin activity). There is no attach diagnostic, no LSM wiring message, and no failure of any kind:

$ grep -iE "krsi|bpf|lsm|attach|denied|EPERM|failed" /tmp/krsi_debug.log
Loading plugin 'krsi' from file /usr/share/falco/plugins/libkrsi.so
    /etc/falco/rules.d/krsi_rules.yaml | schema validation: ok
    rule 'Cat Open via KRSI': ...
    rule 'Sensitive File Access (syscall o io_uring)': ...
Watching file '/etc/falco/rules.d/krsi_rules.yaml'
(433) syscalls in rules: ... bpf ... lsm_get_self_attr, lsm_list_modules, lsm_set_self_attr ...
    Cat Open via KRSI
Opening 'syscall' source with modern BPF probe.

The plugin does not report anything relevant.

Environment

• Falco version: 0.41.3 (x86_64)
• Libs version: 0.21.0
• Plugin API: 3.11.0
• Engine: 0.50.0
• Driver: modern eBPF probe (API 8.0.0, Schema 3.6.0)
• KRSI plugin version: 0.2.0, built from source (falcosecurity/plugins, branch main, commit 7086c69)
• libkrsi.so sha256: cd1ca5800d25bd6eddef66acab8750b754a96a9dac4b95cf9cbeb5546e1ba829
• OS: Ubuntu 24.04.4 LTS
• Kernel: 6.17.0-35-generic
• Installation: plugin built locally with cargo build --release

Note that Falco was downgraded from 0.44.0 to 0.41.3 to match the plugin/engine versions used during testing; the behaviour reported here was observed on 0.41.3.

[leogr]

Hey @fortigate3600,

The current option is syscalls: true, with a trailing s. May you retry with that setting? The README uses the wrong singular spelling, and we should fix it.

Thanks 🙏

[fortigate3600]

hey @leogr,

I corrected the setting to syscall"s" (screenshot attached), but the behaviour is unchanged: with either syscalls: true or syscalls: false.
first attempt with syscalls false:

second attempt with syscalls true: