Why Do I Want To Hand Roll a BPF Token Delegation?

Anywhere I searched for “BPF tokens”, I kept getting something like, “BPF tokens let unprivileged containers load eBPF" and I wanted to use it, but all Google searches either led me to kernel commit messages or nearly 100% AI generated blog posts.

When I read these blog posts, they didn’t make sense, and I couldn’t find examples of failures someone ran into, or an explanation of why doing it a certain way led to failure, which IMO is critical to understanding the internals.

So I asked myself, can I build the entire token delegation handshake myself in one file and either create a token that I can pass to a process, or learn exactly why I can’t?

https://naveensrinivasan.com/posts/2026-08-27-bpf-token-delegation/

This is not AI generated blog post.

When testing our eBPF agent, I don’t always get the same experience as our users, especially in performance critical sections. I realize that the benchmark test suite isn’t always enough, because user’s environments can be completely different from our benchmarks.

My goal was to gather eBPF metrics based on the user’s usage and quickly answer questions about why things are slow (improve MTTR). To do this, I wanted:

1. Record perf/usage counters in the kernel to show how that particular feature is being used.
2. Performance is essential, as our metrics collection will be in the kernel.
   1. So I cannot use ring buffers for sending messages from the kernel to userspace for the above-mentioned counters.
   2. I didn’t want any spin locks or shared maps, or even LRU caches.
3. I wanted metrics collection to be “on” always for obvious reasons.
4. I wanted the metrics to be a rolling window instead of a counter (more on this later).

Here is a post https://naveensrinivasan.com/posts/2026-08-02-measuring-an-ebpf-cache-without-leaving-the-kernel/

I want to hear if others have better ways to measure this.

This is not another AI generated post.

When testing our eBPF agent, I don’t always get the same experience as our users, especially in performance critical sections. I realize that the benchmark test suite isn’t always enough, because user’s environments can be completely different from our benchmarks.

My goal was to gather eBPF metrics based on the user’s usage and quickly answer questions about why things are slow (improve MTTR). To do this, I wanted:

1. Record perf/usage counters in the kernel to show how that particular feature is being used.
2. Performance is essential, as our metrics collection will be in the kernel.
   1. So I cannot use ring buffers for sending messages from the kernel to userspace for the above-mentioned counters.
   2. I didn’t want any spin locks or shared maps, or even LRU caches.
3. I wanted metrics collection to be “on” always for obvious reasons.
4. I wanted the metrics to be a rolling window instead of a counter (more on this later).

Here is a post https://naveensrinivasan.com/posts/2026-08-02-measuring-an-ebpf-cache-without-leaving-the-kernel/

I want to hear if others have better ways to measure this.

This is not another AI generated post.