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:
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
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
|
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.
Molter73
force-pushed
the
mauro/feat/config-hook-loading
branch
from
9c99ec3 to
45914e6
Compare
| .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.
| 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.
3 participants
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