<div id="readability-page-1" class="page"><div><img src="https://devstarsj.github.io/assets/https://images.unsplash.com/photo-1558494949-ef010cbdcc31?w=1200&amp;auto=format&amp;fit=crop"><h2 id="ebpf-in-2026-the-technology-reshaping-linux-networking-security-and-observability">eBPF in 2026: The Technology Reshaping Linux Networking, Security, and Observability</h2>If you’ve used Cilium, Falco, Pixie, or Tetragon in the last few years, you’ve been using eBPF — even if you didn’t know it. Once a niche kernel hacking technique, eBPF has become foundational infrastructure. This post explains what it is, why it matters, and how to start using it.<img src="https://images.unsplash.com/photo-1558494949-ef010cbdcc31?w=800&amp;auto=format&amp;fit=crop" alt="Linux Kernel and Networking"> Photo by Brett Sayles on Unsplash<hr><h2 id="what-is-ebpf">What Is eBPF?</h2>eBPF (extended Berkeley Packet Filter) lets you run sandboxed programs inside the Linux kernel without modifying kernel source code or loading kernel modules. The kernel verifies these programs before running them, guaranteeing safety.Think of it as: a programmable hook into the kernel that is safe, fast, and doesn’t require a reboot.The original BPF was created in 1992 for packet filtering (the <code>tcpdump</code> use case). “Extended” BPF arrived in Linux 3.18 (2014) and turned it into a general-purpose in-kernel VM. By 2020, it had JIT compilation on all major architectures. By 2026, it’s the de facto standard for:<ul><li>Networking: CNI plugins, load balancing, firewalling</li><li>Security: Runtime threat detection, policy enforcement</li><li>Observability: Low-overhead tracing without instrumentation</li></ul><hr><h2 id="how-ebpf-works">How eBPF Works</h2><div><pre><code>User Space Kernel Space
----------- ------------
 
 eBPF bytecode ──────► Verifier (safety check)
 │
 JIT Compiler
 │
 eBPF Program ◄── Hook point (kprobe, tracepoint, XDP...)
 │
 eBPF Maps ◄────────────────────────────────────────
 User app reads ◄───────────── │ │
 maps for data └── Executes on kernel events, writes to maps ──┘
</code></pre></div>Key components:<ol><li>eBPF Programs: Written in restricted C (or Rust), compiled to eBPF bytecode</li><li>Verifier: Kernel-level static analysis — ensures no infinite loops, no unsafe memory access</li><li>JIT Compiler: Translates bytecode to native machine code for near-native performance</li><li>eBPF Maps: Shared key-value stores between kernel programs and user space</li><li>Hook Points: Where programs attach — XDP, tc, kprobes, uprobes, tracepoints, LSM hooks</li></ol><hr><h2 id="use-case-1-high-performance-networking-with-xdp">Use Case 1: High-Performance Networking with XDP</h2>XDP (eXpress Data Path) lets you process packets before the kernel’s networking stack — at the driver level. This enables line-rate packet processing in software.<div><pre><code>// Simple XDP program to drop all packets from a specific IP
#include &lt;linux/bpf.h&gt;
#include &lt;linux/if_ether.h&gt;
#include &lt;linux/ip.h&gt;
#include &lt;bpf/bpf_helpers.h&gt;

struct {
 __uint(type, BPF_MAP_TYPE_HASH);
 __type(key, __u32); // IP address
 __type(value, __u8); // blocklist flag
 __uint(max_entries, 1024);
} blocklist SEC(".maps");

SEC("xdp")
int xdp_filter(struct xdp_md *ctx) {
 void *data = (void *)(long)ctx-&gt;data;
 void *data_end = (void *)(long)ctx-&gt;data_end;
 
 struct ethhdr *eth = data;
 if ((void *)(eth + 1) &gt; data_end)
 return XDP_PASS;
 
 if (eth-&gt;h_proto != __constant_htons(ETH_P_IP))
 return XDP_PASS;
 
 struct iphdr *ip = (void *)(eth + 1);
 if ((void *)(ip + 1) &gt; data_end)
 return XDP_PASS;
 
 __u8 *blocked = bpf_map_lookup_elem(&amp;blocklist, &amp;ip-&gt;saddr);
 if (blocked &amp;&amp; *blocked)
 return XDP_DROP;
 
 return XDP_PASS;
}

char LICENSE[] SEC("license") = "GPL";
</code></pre></div>Load it:<div><pre><code>ip link set dev eth0 xdp obj filter.o sec xdp
</code></pre></div>This drops packets before they even reach the kernel’s network stack — achieving 10-100x better performance than iptables for the same operation.Cilium uses XDP extensively for Kubernetes networking. It replaces kube-proxy entirely, implementing Service load-balancing in eBPF at the XDP layer.<hr><h2 id="use-case-2-zero-overhead-observability">Use Case 2: Zero-Overhead Observability</h2>Traditional observability requires instrumenting your code or running sidecar proxies. eBPF enables zero-instrumentation observability — you get data without changing your application at all.<div><pre><code># bcc (BPF Compiler Collection) Python example
# Traces all HTTP requests across all processes without any app changes

from bcc import BPF

program = """
#include &lt;uapi/linux/ptrace.h&gt;

int trace_read(struct pt_regs *ctx) {
 char buf[128];
 u32 pid = bpf_get_current_pid_tgid() &gt;&gt; 32;
 
 bpf_probe_read_user(buf, sizeof(buf), (void *)PT_REGS_PARM2(ctx));
 
 // Filter for HTTP methods
 if (buf[0] == 'G' &amp;&amp; buf[1] == 'E' &amp;&amp; buf[2] == 'T' ||
 buf[0] == 'P' &amp;&amp; buf[1] == 'O' &amp;&amp; buf[2] == 'S') {
 bpf_trace_printk("PID %d: %s\\n", pid, buf);
 }
 return 0;
}
"""

b = BPF(text=program)
b.attach_uprobe(name="c", sym="read", fn_name="trace_read")

print("Tracing HTTP reads... Ctrl+C to stop")
b.trace_print()
</code></pre></div>Tools built on this principle:<ul><li>Pixie: Full-body request tracing for Kubernetes, zero instrumentation</li><li>Hubble: Network flow visibility for Cilium</li><li>Pyroscope + eBPF: Continuous profiling without code changes</li><li>Parca: Always-on profiling at 1% CPU overhead</li></ul><hr><h2 id="use-case-3-runtime-security-with-lsm-hooks">Use Case 3: Runtime Security with LSM Hooks</h2>eBPF + Linux Security Module (LSM) hooks enable runtime security policies that are:<ul><li>Applied without rebooting</li><li>Updated without downtime</li><li>Capable of blocking, not just alerting</li></ul>Tetragon by Cilium is the production implementation:<div><pre><code># Tetragon policy: Block access to /etc/passwd from non-root
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
 name: "block-passwd-access"
spec:
 kprobes:
 - call: "security_file_open"
 syscall: false
 args:
 - index: 0
 type: "file"
 selectors:
 - matchArgs:
 - index: 0
 operator: "Postfix"
 values:
 - "/etc/passwd"
 matchCapabilities:
 - type: Effective
 operator: NotIn
 values:
 - "CAP_SETUID"
 matchActions:
 - action: Sigkill
</code></pre></div>When a non-privileged process tries to open <code>/etc/passwd</code>, the kernel kills it immediately. No userspace daemon in the hot path. This is fundamentally different from seccomp — you can match on file paths, network connections, and process ancestry.<hr><h2 id="use-case-4-service-mesh-without-sidecars">Use Case 4: Service Mesh Without Sidecars</h2>The traditional service mesh model (Istio, Linkerd) injects a proxy sidecar into every pod. This adds:<ul><li>~50ms latency per hop</li><li>Memory overhead per pod</li><li>Complex certificate management</li></ul>eBPF-based service mesh (Cilium Service Mesh, Merbridge) implements mTLS, traffic policy, and observability in the kernel:<div><pre><code>Traditional: eBPF-based:
App → Sidecar proxy → App → eBPF socket hook →
Network → Sidecar → Network (kernel) →
App App
</code></pre></div>Benchmark results from Cilium’s 2026 report:<ul><li>Latency: 3.8ms (eBPF) vs 12.4ms (sidecar) at P99</li><li>CPU: 0.3 cores/node (eBPF) vs 1.2 cores/node (sidecar)</li><li>Memory: 45MB/node (eBPF) vs 180MB/node (sidecar)</li></ul><hr><h2 id="getting-started">Getting Started</h2><h3 id="option-1-use-existing-ebpf-based-tools">Option 1: Use Existing eBPF-based Tools</h3>The easiest path — these already run eBPF under the hood:<div><pre><code># Install Cilium (Kubernetes CNI + network policy)
helm repo add cilium https://helm.cilium.io/
helm install cilium cilium/cilium --namespace kube-system

# Install Tetragon (runtime security)
helm install tetragon cilium/tetragon --namespace kube-system

# Install Pixie (observability)
px deploy
</code></pre></div><h3 id="option-2-write-ebpf-programs-with-libbpf">Option 2: Write eBPF Programs with libbpf</h3>For custom use cases:<div><pre><code># Install libbpf and clang
apt install clang llvm libelf-dev linux-headers-$(uname -r)

# Compile
clang -O2 -target bpf -c my_program.c -o my_program.o

# Load with bpftool
bpftool prog load my_program.o /sys/fs/bpf/my_program
bpftool net attach xdp pinned /sys/fs/bpf/my_program dev eth0
</code></pre></div><h3 id="option-3-use-ebpf-go-or-libbpf-rs">Option 3: Use eBPF-go or libbpf-rs</h3>For production Go or Rust programs:<div><pre><code>// eBPF-go example
//go:generate go run github.com/cilium/ebpf/cmd/bpf2go -cc clang Filter filter.c

func main() {
 objs := FilterObjects{}
 if err := LoadFilterObjects(&amp;objs, nil); err != nil {
 log.Fatal(err)
 }
 defer objs.Close()

 link, err := link.AttachXDP(link.XDPOptions{
 Program: objs.XdpFilter,
 Interface: iface.Index,
 })
 if err != nil {
 log.Fatal(err)
 }
 defer link.Close()
 
 // Read from maps, update blocklist, etc.
}
</code></pre></div><hr><h2 id="limitations-and-gotchas">Limitations and Gotchas</h2><ol><li>Kernel version requirements: Many features require Linux 5.8+. Check <code>CONFIG_BPF_SYSCALL</code>, <code>CONFIG_DEBUG_INFO_BTF</code>.</li><li>Verifier complexity: The verifier rejects valid-looking programs. Loops require bounded iteration counts. The error messages are… cryptic.</li><li>BTF (BPF Type Format): Required for CO-RE (Compile Once, Run Everywhere). Most modern distros ship with BTF enabled, but check <code>/sys/kernel/btf/vmlinux</code>.</li><li>Not for Windows: eBPF for Windows exists but is immature. eBPF is fundamentally a Linux technology.</li><li>Security of eBPF itself: eBPF programs with <code>CAP_BPF</code> capability can read kernel memory. Compromised eBPF is very powerful. Audit what you load.</li></ol><hr><h2 id="the-2026-landscape">The 2026 Landscape</h2>eBPF has crossed the chasm. It’s no longer “interesting kernel tech” — it’s infrastructure:<ul><li>Every major cloud CNI (Cilium, Calico, AWS VPC CNI) now uses eBPF</li><li>Kubernetes 1.33 includes eBPF-accelerated service proxy as stable</li><li>Falco 2.0 moved its core detection engine to eBPF</li><li>Linux 6.9 extended eBPF capabilities for socket policy and HID devices</li></ul>If you’re building or operating cloud infrastructure in 2026 and don’t understand eBPF, you’re increasingly flying blind. The observability, security, and networking tools you rely on are built on it.<hr>Start with <code>bpftrace</code> for ad-hoc kernel debugging. Move to <code>bcc</code> for more structured programs. Use <code>libbpf</code> + CO-RE for production code. And take the <a href="https://ebpf.io/">eBPF.io</a> tour — it’s the best introduction available.<img src="https://images.unsplash.com/photo-1515879218367-8466d910aaa4?w=800&amp;auto=format&amp;fit=crop" alt="eBPF Ecosystem"> Photo by Chris Ried on UnsplashThe kernel is programmable now. Use it. <div>이 글이 도움이 되셨다면 공감 및 광고 클릭을 부탁드립니다 :) </div></div></div>

Dev Note

eBPF in 2026: The Technology Reshaping Linux Networking, Security, and Observability
If you’ve used Cilium, Falco, Pixie, or Tetragon in the last few years, you’ve been using eBPF — even if you didn’t know it. Once a niche kernel hacking technique, eBPF has become foundational infrastructure. This post explains what it is, why it matters, and how to start using it.
Photo by Brett Sayles on Unsplash
What Is eBPF?
eBPF (extended Berkeley Packet Filter) lets you run sandboxed programs inside the Linux kernel without modifying kernel source code or loading kernel modules. The kernel verifies these programs before running them, guaranteeing safety.
Think of it as: a programmable hook into the kernel that is safe, fast, and doesn’t require a reboot.
The original BPF was created in 1992 for packet filtering (the tcpdump use case). “Extended” BPF arrived in Linux 3.18 (2014) and turned it into a general-purpose in-kernel VM. By 2020, it had JIT compilation on all major architectures. By 2026, it’s the de facto standard for:
Networking: CNI plugins, load balancing, firewalling
Security: Runtime threat detection, policy enforcement
Observability: Low-overhead tracing without instrumentation
How eBPF Works
User Space Kernel Space
----------- ------------
 
 eBPF bytecode ──────► Verifier (safety check)
 │
 JIT Compiler
 │
 eBPF Program ◄── Hook point (kprobe, tracepoint, XDP...)
 │
 eBPF Maps ◄────────────────────────────────────────
 User app reads ◄───────────── │ │
 maps for data └── Executes on kernel events, writes to maps ──┘
Key components:
eBPF Programs: Written in restricted C (or Rust), compiled to eBPF bytecode
Verifier: Kernel-level static analysis — ensures no infinite loops, no unsafe memory access
JIT Compiler: Translates bytecode to native machine code for near-native performance
eBPF Maps: Shared key-value stores between kernel programs and user space
Hook Points: Where programs attach — XDP, tc, kprobes, uprobes, tracepoints, LSM hooks
Use Case 1: High-Performance Networking with XDP
XDP (eXpress Data Path) lets you process packets before the kernel’s networking stack — at the driver level. This enables line-rate packet processing in software.
// Simple XDP program to drop all packets from a specific IP
#include <linux/bpf.h>
#include <linux/if_ether.h>
#include <linux/ip.h>
#include <bpf/bpf_helpers.h>
struct {
 __uint(type, BPF_MAP_TYPE_HASH);
 __type(key, __u32); // IP address
 __type(value, __u8); // blocklist flag
 __uint(max_entries, 1024);
} blocklist SEC(".maps");
SEC("xdp")
int xdp_filter(struct xdp_md *ctx) {
 void *data = (void *)(long)ctx->data;
 void *data_end = (void *)(long)ctx->data_end;
 
 struct ethhdr *eth = data;
 if ((void *)(eth + 1) > data_end)
 return XDP_PASS;
 
 if (eth->h_proto != __constant_htons(ETH_P_IP))
 return XDP_PASS;
 
 struct iphdr *ip = (void *)(eth + 1);
 if ((void *)(ip + 1) > data_end)
 return XDP_PASS;
 
 __u8 *blocked = bpf_map_lookup_elem(&blocklist, &ip->saddr);
 if (blocked && *blocked)
 return XDP_DROP;
 
 return XDP_PASS;
}
char LICENSE[] SEC("license") = "GPL";
Load it:
ip link set dev eth0 xdp obj filter.o sec xdp
This drops packets before they even reach the kernel’s network stack — achieving 10-100x better performance than iptables for the same operation.
Cilium uses XDP extensively for Kubernetes networking. It replaces kube-proxy entirely, implementing Service load-balancing in eBPF at the XDP layer.
Use Case 2: Zero-Overhead Observability
Traditional observability requires instrumenting your code or running sidecar proxies. eBPF enables zero-instrumentation observability — you get data without changing your application at all.
# bcc (BPF Compiler Collection) Python example
# Traces all HTTP requests across all processes without any app changes
from bcc import BPF
program = """
#include <uapi/linux/ptrace.h>
int trace_read(struct pt_regs *ctx) {
 char buf[128];
 u32 pid = bpf_get_current_pid_tgid() >> 32;
 
 bpf_probe_read_user(buf, sizeof(buf), (void *)PT_REGS_PARM2(ctx));
 
 // Filter for HTTP methods
 if (buf[0] == 'G' && buf[1] == 'E' && buf[2] == 'T' ||
 buf[0] == 'P' && buf[1] == 'O' && buf[2] == 'S') {
 bpf_trace_printk("PID %d: %s\\n", pid, buf);
 }
 return 0;
}
"""
b = BPF(text=program)
b.attach_uprobe(name="c", sym="read", fn_name="trace_read")
print("Tracing HTTP reads... Ctrl+C to stop")
b.trace_print()
Tools built on this principle:
Pixie: Full-body request tracing for Kubernetes, zero instrumentation
Hubble: Network flow visibility for Cilium
Pyroscope + eBPF: Continuous profiling without code changes
Parca: Always-on profiling at 1% CPU overhead
Use Case 3: Runtime Security with LSM Hooks
eBPF + Linux Security Module (LSM) hooks enable runtime security policies that are:
Applied without rebooting
Updated without downtime
Capable of blocking, not just alerting
Tetragon by Cilium is the production implementation:
# Tetragon policy: Block access to /etc/passwd from non-root
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
 name: "block-passwd-access"
spec:
 kprobes:
 - call: "security_file_open"
 syscall: false
 args:
 - index: 0
 type: "file"
 selectors:
 - matchArgs:
 - index: 0
 operator: "Postfix"
 values:
 - "/etc/passwd"
 matchCapabilities:
 - type: Effective
 operator: NotIn
 values:
 - "CAP_SETUID"
 matchActions:
 - action: Sigkill
When a non-privileged process tries to open /etc/passwd, the kernel kills it immediately. No userspace daemon in the hot path. This is fundamentally different from seccomp — you can match on file paths, network connections, and process ancestry.
Use Case 4: Service Mesh Without Sidecars
The traditional service mesh model (Istio, Linkerd) injects a proxy sidecar into every pod. This adds:
~50ms latency per hop
Memory overhead per pod
Complex certificate management
eBPF-based service mesh (Cilium Service Mesh, Merbridge) implements mTLS, traffic policy, and observability in the kernel:
Traditional: eBPF-based:
App → Sidecar proxy → App → eBPF socket hook →
Network → Sidecar → Network (kernel) →
App App
Benchmark results from Cilium’s 2026 report:
Latency: 3.8ms (eBPF) vs 12.4ms (sidecar) at P99
CPU: 0.3 cores/node (eBPF) vs 1.2 cores/node (sidecar)
Memory: 45MB/node (eBPF) vs 180MB/node (sidecar)
Getting Started
Option 1: Use Existing eBPF-based Tools
The easiest path — these already run eBPF under the hood:
# Install Cilium (Kubernetes CNI + network policy)
helm repo add cilium https://helm.cilium.io/
helm install cilium cilium/cilium --namespace kube-system
# Install Tetragon (runtime security)
helm install tetragon cilium/tetragon --namespace kube-system
# Install Pixie (observability)
px deploy
Option 2: Write eBPF Programs with libbpf
For custom use cases:
# Install libbpf and clang
apt install clang llvm libelf-dev linux-headers-$(uname -r)
# Compile
clang -O2 -target bpf -c my_program.c -o my_program.o
# Load with bpftool
bpftool prog load my_program.o /sys/fs/bpf/my_program
bpftool net attach xdp pinned /sys/fs/bpf/my_program dev eth0
Option 3: Use eBPF-go or libbpf-rs
For production Go or Rust programs:
// eBPF-go example
//go:generate go run github.com/cilium/ebpf/cmd/bpf2go -cc clang Filter filter.c
func main() {
 objs := FilterObjects{}
 if err := LoadFilterObjects(&objs, nil); err != nil {
 log.Fatal(err)
 }
 defer objs.Close()
 link, err := link.AttachXDP(link.XDPOptions{
 Program: objs.XdpFilter,
 Interface: iface.Index,
 })
 if err != nil {
 log.Fatal(err)
 }
 defer link.Close()
 
 // Read from maps, update blocklist, etc.
}
Limitations and Gotchas
Kernel version requirements: Many features require Linux 5.8+. Check CONFIG_BPF_SYSCALL, CONFIG_DEBUG_INFO_BTF.
Verifier complexity: The verifier rejects valid-looking programs. Loops require bounded iteration counts. The error messages are… cryptic.
BTF (BPF Type Format): Required for CO-RE (Compile Once, Run Everywhere). Most modern distros ship with BTF enabled, but check /sys/kernel/btf/vmlinux.
Not for Windows: eBPF for Windows exists but is immature. eBPF is fundamentally a Linux technology.
Security of eBPF itself: eBPF programs with CAP_BPF capability can read kernel memory. Compromised eBPF is very powerful. Audit what you load.
The 2026 Landscape
eBPF has crossed the chasm. It’s no longer “interesting kernel tech” — it’s infrastructure:
Every major cloud CNI (Cilium, Calico, AWS VPC CNI) now uses eBPF
Kubernetes 1.33 includes eBPF-accelerated service proxy as stable
Falco 2.0 moved its core detection engine to eBPF
Linux 6.9 extended eBPF capabilities for socket policy and HID devices
If you’re building or operating cloud infrastructure in 2026 and don’t understand eBPF, you’re increasingly flying blind. The observability, security, and networking tools you rely on are built on it.
Start with bpftrace for ad-hoc kernel debugging. Move to bcc for more structured programs. Use libbpf + CO-RE for production code. And take the eBPF.io tour — it’s the best introduction available.
Photo by Chris Ried on Unsplash
The kernel is programmable now. Use it.

eBPF in 2026: The Technology Reshaping Linux Networking, Security, and Observability

댓글