Uh oh!
There was an error while loading. Please reload this page.
feat(config): configurable loaded BPF programs - #1086
Conversation
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yml Review profile: CHILL Plan: Enterprise Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (6)
🚧 Files skipped from review as they are similar to previous changes (5)
📝 WalkthroughWalkthroughBPF configuration now supports per-program enablement, YAML parsing and merging, configuration-aware eBPF loading, validation, and structured attachment errors. Tests cover parsing, invalid configurations, updates, enablement behavior, and program validation. ChangesBPF configuration and loading
Estimated code review effort: 3 (Moderate) | ~25 minutes Sequence Diagram(s)sequenceDiagram
participant Bpf_new
participant load_ebpf
participant load_progs
participant BpfConfig
participant attach_progs
participant EbpfObject
Bpf_new->>load_ebpf: pass checks and BpfConfig
load_ebpf->>EbpfObject: load configured maps and object
Bpf_new->>load_progs: pass Btf and BpfConfig
load_progs->>BpfConfig: query program_is_enabled
load_progs->>EbpfObject: load enabled supported hooks
Bpf_new->>attach_progs: attach loaded programs
attach_progs->>EbpfObject: create LSM links
Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@## main #1086 +/- ##
==========================================
+ Coverage 32.95% 33.51% +0.56%
==========================================
Files 21 21 Lines 2971 3043 +72 Branches 2971 3043 +72 ==========================================
+ Hits 979 1020 +41 - Misses 1989 2019 +30 - Partials 3 4 +1 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@fact/src/bpf/mod.rs`:
- Around line 53-56: Update the Bpf::validate_config call in the loading flow to
enforce its boolean result: continue only when validation succeeds, and return
an error through the existing load path when it returns false. Preserve the
current behavior for valid configurations while preventing startup with unknown
bpf.programs entries.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yml
Review profile: CHILL
Plan: Enterprise
Run ID: db314835-ed6f-465f-9051-cb085fa2188a
⛔ Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (5)
fact/Cargo.tomlfact/src/bpf/checks.rsfact/src/bpf/mod.rsfact/src/config/mod.rsfact/src/config/tests.rs
Uh oh!
There was an error while loading. Please reload this page.
Molter73
commented
Jul 14, 2026
As discussed in #1049 (comment), at this time, implementing this configuration through environment variables or cli arguments will most likely require them to be expressed as JSON encoded strings, which is finicky and prone to escaping errors. So for the time being, the implementation is restricted to configuration files. |
This patch makes it possible to decide at runtime which BPF programs should be loaded. To make the code as flexible as possible the configuration side stores the programs in a map, then the bpf side validates the configuration to notify if an unknown BPF program is found. Default behavior is still loading and attaching all BPF programs.
9c99ec3 to
45914e6Compare| .load(fact_ebpf::EBPF_OBJ)?; | ||
| let obj = Bpf::load_ebpf(&checks, bpf_config)?; | ||
| Bpf::validate_config(&obj, bpf_config); |
There was a problem hiding this comment.
Nothing is done with the return value from validate_config.
There was a problem hiding this comment.
No, I added the return value explicitly for unit tests. At the moment, all we do is find program names that are not found in our eBPF object and print a warn statement if that happens, I don't think further action than that is needed, WDYT?
| u => unimplemented!("{u:?}"), | ||
| } | ||
| } | ||
| self.links = self |
There was a problem hiding this comment.
Do we still need self.links.clear()? I think we don't really need it, but it would be a bit safer to keep it.
if self.links.is_empty() {
self.attach_progs()?;
}
This is the only place that attach_progs is used, and it is only called if self.links is empty and errors in attach_progs are handled. I think an error would result in self.links maintaining its value.
There was a problem hiding this comment.
No, we don't need it. This is closer to the original implementation of attach_progs that was changed in #878. With the current approach, all attached programs are first dettached, then reattached, which causes a moment where we have no visibility into events being triggered from the kernel. With the approach I'm proposing, the programs are first attached, the links are placed in a new vector, the vectors are then swapped and the old one is dropped, in turn detaching the old attachments. This new approach produces a moment where we might get duplicated events, but I think that is better than having a blind spot.
In any case, this method is only called when there are no links attached ATM, so it is not very important, but if it changes, I think we want this behavior.
| } | ||
| for (k, v) in &from.programs { | ||
| self.programs.entry(k.clone()).or_default().update(v); |
There was a problem hiding this comment.
This only adds programs it never removes them, event if programs have been removed from the config.
There was a problem hiding this comment.
My original intent with this implementation is that the Reloader program creates a new version of the configuration from scratch each time it runs, the update method is used to layer on the different files/env var/CLI arguments it finds. In turn, this means that if a program is removed from the configuration, it will not be present in the new iteration that will be created when the Reloader runs. In any case, this configuration is not hot-reloadable so this will only come into play if this changes in the future.
For the current state of things, we don't really have the semantics in place to signal "we want to remove this program in this layer", since a layer that doesn't add the program might only mean we don't want to change it in any way. In any case, what a user can do is explicitly change the configuration for the program on a separate layer. This is expressed in the added update unit test cases.
Uh oh!
There was an error while loading. Please reload this page.
Description
This patch makes it possible to decide at runtime which BPF programs should be loaded.
To make the code as flexible as possible the configuration side stores the programs in a map, then the bpf side validates the configuration to notify if an unknown BPF program is found.
Default behavior is still loading and attaching all BPF programs.
Checklist
Automated testing
If any of these don't apply, please comment below.
Testing Performed
output of `bpftool prog list` with `file_open` and `inode_setxattr` disabled
Summary by CodeRabbit
Summary by CodeRabbit
New Features
bpf.programsconfiguration to enable/disable specific BPF programs viaenabled.Bug Fixes
Tests
bpf.programs.Documentation