eBPF Security Agent Slashes CPU Cost 90% with Inode Memoization
Dropping eBPF CPU Cost by About 90% with Memoization (Not AI Gen)
My brother and I designed our eBPF security agent for speed, but profiling revealed that enforcing path-based policies—not the allow/deny decision—was the real bottleneck. By caching the applicable policy per inode (keyed by mount namespace, mount ID, and inode number), we cut kernel CPU cost by about 90% in benchmarks. The cache handles edge cases like hardlinks by falling back to the slow path when link count exceeds one. We've open-sourced the repo.
So, we cache which policy applies for each inode. This dropped our kernel CPU cost by about 90%.
- Allybag
Seems like the 90% faster case is opening the same exact file every single time, which seems like a not super standard use case that will benefit the most from this caching. On an example where you never open the same file twice this will presumably be slightly slower than before, as you’re doing the same thing but writing to a cache.
So you can make the headline “Drop performance cost by 90%!” or “Modestly increase performance cost” and be correct but I don’t think either is really a reasonable description of the change.
- danudey
Very confused by the article. Is memoization new to the eBPF world? Did the author only just learn about it and wanted to use it?
In reality, the article is about correctly caching a path:policy mapping while working within the limitations of eBPF and Linux filesystem semantics. If you read the article in that context rather than wondering 'what is new and interesting about memoization in eBPF?' it's a lot more interesting.
I probably would have titled this 'Calculating cache keys for filesystem paths in eBPF' or something, since that's the cool and interesting problem that was solved.
- ComputerGuru
How do your path-only rules handle the many approaches for loading a file but making it appear to have a different path, such as bind mounts for one example?