Linux eBPF: verifier scope and choosing an observation point
Separate the memory and type constraints checked by the eBPF verifier from application correctness, then choose an operational check sequence that accounts for kernel, hook, and XDP mode.
Publication & corrections: infostoa · Editorial standards
Individual author and specialist reviewer information is not provided for this article.
What eBPF changes—and what it does not
eBPF lets programs extend selected kernel facilities; it is not a general replacement for kernel modules. A program is constrained by its program type, attachment point, and the helpers and features allowed by the target kernel. During load, the verifier checks constraints such as initialized registers and stack, pointer types and bounds, context-specific access, and helper arguments. Passing means those verifier constraints were met; it does not prove that an application policy is correct or that every runtime failure is impossible. Support and load results vary with program type, permissions, kernel version, and configuration.
Modern kernels can support some bounded loops under verifier constraints, but that does not mean every loop is accepted on every kernel. Complexity limits and state analysis can still reject a program. Load it on a kernel matching the deployment target and inspect the verifier log. Depending on architecture, configuration, and policy, JIT may translate bytecode into native instructions; that alone does not establish a performance target.
Attachment point changes what you can observe
Tracing programs select an attachment point and program type for a purpose, such as a tracepoint, kprobe, or uprobe. Do not assume a point exists or has identical meaning on every kernel. Check the target kernel’s BTF, supported program types and helpers, and required privileges. BPF maps also do not all behave like lock-free exchange tables: access and concurrency semantics depend on the map type. Check shared-counter updates, user-space consumption, and event loss separately.
XDP has three modes. Native XDP runs early in the receive path of a supporting driver; generic XDP runs later in the network stack; offloaded XDP runs on supported NIC hardware. Cilium XDP acceleration likewise depends on configuration and device support. Packets handled at XDP may not appear in a tcpdump attached farther along the path, so an empty capture alone does not prove that no packet was processed.
Hypothetical incident: expected packets are missing from a capture
This is a hypothetical workflow, not a measured result. Suppose an operator cannot find expected NodePort packets in tcpdump on a Cilium node.
| Check | Evidence to inspect | Interpretation and next check |
|---|---|---|
| 1. Attachment | XDP state from ip link, Cilium XDP status, and interface driver | Confirm the mode and device. If they differ from expectations, investigate configuration or driver support first. |
| 2. Capture point | tcpdump attachment point in the packet path and XDP counters | Native XDP can process packets before a later capture point. Choose counters or capture points on the relevant side of XDP. |
| 3. Program load | Program type, verifier log, kernel version, and privileges | A rejection may reflect a verifier constraint or unsupported feature. Match the first rejected instruction to target-kernel support. |
| 4. Load and loss | Throughput, CPU, map contention, ring-buffer loss and consumer lag | For missing events, compare production rate, consumption rate, event size, and collection cost before merely enlarging buffers. |
Start with one observation question and a minimal hook. Load it on an isolated kernel matching the target, then check counters and loss. Under representative load, compare CPU and latency with a baseline. This article does not claim that a kernel load, Cilium deployment, or performance benchmark was run.
Sources: Linux eBPF verifier, Linux BPF design Q&A, Cilium XDP program types, Cilium XDP acceleration