eBPF - The latest news, updates and articles covering eBPF and related topics.

Cloudflare’s eBPF Replatforming Part 1: The eBPF Pivot – From Hardware Lock-in to Programmable Networking

Thu, 27 Aug 2026 17:00:00 GMT

By Cloudflare Engineering

This series chronicles Cloudflare’s eight-year journey with eBPF from a specialized DDoS tool to the programmable backbone of their global network. It covers everything from contributing to the Linux kernel and technical challenges to business ROI to advice and operational strategies for other companies adopting eBPF.

Cloudflare began exploring eBPF/XDP in late 2016, with prototyping for load balancing starting mid-2017. Our first production deployment was in November 2018, when we launched XDP-based packet filtering (l4drop) for L3/L4 DDoS mitigation. This replaced our previous kernel-bypass solution that was tied to a specific NIC vendor.

Cloudflare’s investment in eBPF was driven by a convergence of hardware constraints, performance requirements, and the need to eliminate accumulated technical debt. This is how we arrived at the decision to replatform, why we decided to center around eBPF, and where we use the technology today.

The Catalyst: Breaking Free from Hardware Lock-in

The immediate trigger to look at eBPF was our previous DDoS mitigation solution, which relied on a proprietary RDMA stack for kernel bypass packet processing. This created a single-vendor dependency. When we started deploying ARM-based servers and newer NICs for our 25G network upgrade, we hit a wall. These platforms were incompatible with the proprietary stack.

We needed a vendor-agnostic solution. eBPF, specifically XDP (eXpress Data Path), gave us exactly that. It works with any NIC that supports XDP in the driver and allowed us to diversify our hardware suppliers without rewriting our packet processing logic.

XDP: Performance Without Compromise

We needed to drop packets at rates exceeding 10 million packets per second during DDoS attacks while minimizing CPU overhead. Full kernel bypass solutions like DPDK exist, but they require dedicating the entire network card to a single application. They also break standard Linux tools like ssh and tcpdump and prevent running multiple applications on the same server.

XDP gave us a “partial kernel bypass”. eBPF programs run at the earliest possible point in the network stack, directly in the NIC driver, achieving near-line-rate packet processing with minimal CPU overhead (around 10% during massive attacks), while still retaining the full Linux ecosystem tooling.

Replacing Technical Debt

During the growth of Cloudflare, we had accumulated significant workarounds over the years and were looking for ways to reduce our technical debt including:

BIND_TO_PREFIX: A custom kernel patch we maintained ourselves with no upstream acceptance
TPROXY: Complex to set up and maintain, with subtle interactions with the network stack
Tens of thousands of IP bindings in our DNS resolver leading to massive socket overhead just for DDoS protection

eBPF allowed us to replace all of these with cleaner, more maintainable solutions.

Why an eBPF Based Platform Approach?

The decision to use eBPF across our entire stack rather than as point solutions came down to architectural reality and operational efficiency.

Mutual Exclusivity: XDP and kernel bypass are incompatible. You cannot run both simultaneously. When we chose XDP for our L4 load balancer (Unimog), we were forced to migrate DDoS mitigation to XDP as well. This wasn’t a disadvantage; it was an opportunity to unify.

Service Multiplexing: We run dozens of services on each edge server: nginx, DNS resolvers, Spectrum, WARP, and more. The traditional BSD socket model of “one socket per port” simply doesn’t work at our scale. We need different applications sharing port 80 or 53, and for Spectrum, we need access to all port numbers. BPF socket dispatch (via the sk_lookup hook we contributed upstream) enables this dynamic routing without service restarts.

Composability: eBPF programs can be chained using tail calls. A single XDP hook can run DDoS mitigation, then load balancing, then connection tracking, all as modular, independently deployable programs. Buying into eBPF as a platform allowed us to extract additional value with each new feature we needed.

Unified Operations: One platform means one deployment mechanism, consistent configuration distribution, unified Prometheus metrics, and common debugging tools. Point solutions would fragment operations across different systems with different deployment, monitoring, and debugging approaches.

Where We Use eBPF Today

Cloudflare utilizes eBPF at six distinct layers:

DDoS Mitigation (XDP): L4Drop replaces our previous kernel-bypass solution, dropping volumetric attacks at the driver level
Load Balancing (XDP): Unimog handles ECMP routing and fine-grained server load balancing
Socket Dispatch (sk_lookup): Tubular steers traffic dynamically to services sharing IPs and ports
Firewalling: Magic Firewall uses eBPF for deep packet inspection where static nftables rules fall short
Observability: ebpf_exporter generates kernel-level histograms with low overhead
Reliability: udpgrm enables graceful restarts for UDP protocols like QUIC

Betting on the eBPF Ecosystem for Cloudflare’s Platform

The alternative to an eBPF platform was maintaining multiple incompatible point solutions, each with its own hardware dependencies, operational quirks, and integration challenges. As our hardware diversified, performance requirements grew, and edge services multiplied, that approach became untenable.

eBPF gave us a unified, vendor-agnostic, high-performance foundation that lets us program the operating system itself to handle our scale. The kernel verifier ensures safety where we can deploy complex logic changes on the fly without risking system crashes. That flexibility is critical when every edge server runs the entire software stack and must adapt to traffic changes instantly.

In the next parts of the series, we will walk through how betting on eBPF as a platform has paid off both technically and for the business bottom line, and the challenges faced along the way.

How LinkedIn Identified a Kernel Lock Contention Issue Causing Recurring System Freezes

Wed, 27 May 2026 17:00:00 GMT

When LinkedIn engineers encountered short-lived, recurring outages where the database powering their user feed became unavailable and then recovered without leaving helpful traces, they had to devise a novel approach to uncover the root cause using off-CPU profiling with eBPF.

How Cloudflare responded to the “Copy Fail” Linux vulnerability

Thu, 07 May 2026 17:00:00 GMT

Responsible disclosure works, in-kernel visibility tooling pays off in moments exactly like this one, and bpf-lsm continues to be one of the most useful primitives we have for runtime kernel mitigation.

The invisible engineering behind Lambda's network

Wed, 22 Apr 2026 17:00:00 GMT

How eBPF took Lambda from 125,000 iptables rules to 144 and scaled snapshot networks by 20x.

How GitHub uses eBPF to improve deployment safety

Thu, 16 Apr 2026 17:00:00 GMT

Learn how Github uses eBPF to detect and prevent circular dependencies in its deployment tooling.

How Nutanix AHV Uses eBPF for vNIC-IP Mapping

Thu, 29 Jan 2026 17:00:00 GMT

Nutanix AVH leverages eBPF and Ring Buffer for timely and accurate vNIC-to-IP association

Hardening eBPF for runtime security: Lessons from Datadog Workload Protection

Wed, 07 Jan 2026 17:00:00 GMT

Why Datadog chose eBPF for Workload Protection and lessons learned from implementation

Community Built! Results from eBPF Summit: Hackathon Edition 2025

Tue, 06 Jan 2026 17:00:00 GMT

Read about the winning projects of the hackathon and the new eBPF trends!

The eBPF Foundation’s 2025 Year in Review

Thu, 18 Dec 2025 17:00:00 GMT

Funding everything from academic research to conferences to fellowships

Scaling real-time file monitoring with eBPF: How we filtered billions of kernel events per minute

Tue, 18 Nov 2025 17:00:00 GMT

Building file integrity monitoring on top of eBPF at Datadog

eBPF Foundation Announces Community & Advocacy Fellowship Program

Thu, 14 Aug 2025 11:52:00 GMT

The fellowship is a six-month grant for individuals who want to dedicate their time to growing and educating the eBPF community

Testing eBPF Program Compatibility Across Kernels with LVH and GitHub Actions

Tue, 08 Jul 2025 17:00:00 GMT

GitHub Actions Meets Little VM Helper and eBPF

Breaking Boundaries: Implementing the Enigma Machine in eBPF

Mon, 23 Jun 2025 00:00:00 GMT

André Martins celebrates Alan Turing 113th posthumous birthday by implementing the Enigma machine in eBPF

Why Does My eBPF Program Work on One Kernel but Fail on Another?

Tue, 22 Apr 2025 09:55:00 GMT

Learn how to make eBPF programs portable across different Linux kernels using BPF CO-RE and BTF, and discover techniques for supporting systems without built-in BTF by embedding external BTF data.

eBPF Announces Support for Tolkien Ring

Tue, 01 Apr 2025 10:00:00 GMT

Author: Bill Mulligan - Isovalent

Before WiFi there was Ethernet. Before Ethernet there was Token Ring. And before Token Ring there was Tolkien Ring. Before Tolkien Ring, the packets wandered without purpose, lost to the void.

Now support for Tolkien Ring is coming to eBPF. Since its humble beginnings as a packet processor, eBPF has expanded to become a general purpose runtime enabling developers to extend and rebuild whole swaths of the kernel better from low overhead observability to granular security, optimized scheduling, and continuous profiling. eBPF is now returning to its roots with its most ambitious project yet, native support for the original networking protocol Tolkien Ring.

For those unfamiliar, Tolkien Ring is the oldest networking protocol, established in the Days of Númenor, when the world was young and packets were not yet buried under layers of abstraction. It was the first fully decentralized, peer-to-peer network where messages were passed by whispers on the wind, encoded in runes, and secured by the strength of oaths. But as time passed, its wisdom was lost, replaced by lesser protocols constrained by mere physical wires and fleeting radio waves, forgotten by all but the wisest maintainers. Now, thanks to eBPF, this ancient technology is being restored to its former glory.

“eBPF already transformed networking at Meta twice, first with Katran processing millions of packets of cat pictures per second then again with netkit making container networking with isolation from orcs as fast as host networking.” said Alexei Starovoitov eBPF co-founder and co-maintainer. “We’ve also seen eBPF expand into networking use cases we never imagined like HTTP parsing in the kernel or a Layer 2 switch in Kubernetes for VMs, but bringing back Tolkien Ring was a challenge unlike any other. Half the documentation was in Elvish and the other half was a subdialect of Dwarvish last recorded in the times of Moria’s First Age maintainers. Adapting Tolkien Ring to modern infrastructure required pushing eBPF to its limits, but in the end, it was the only technology capable of binding them all.”

Integrating Tolkien Ring into the kernel came with a few surprises. For example, Tolkien Ring does not retransmit packets, it simply ensures they arrive precisely when they are meant to. Packet loss is not a possibility but a matter of destiny, and unlike conventional cryptographic handshakes, Tolkien Ring’s security model is built on binding oaths, which once sworn, cannot be revoked. eBPF maintainers also had to fight hard against the Tolkien Ring Wraiths: the Nine were once features, but time and corruption had turned them into CI flakes. Happily, all fell back into order after a few additional patches, which saved everybody a trip to Mount Doom.

The verifier also required substantial updates. While it was already capable of checking programs for unsafe memory access, ensuring programs run to completion and do not crash or otherwise harm the system, and allowing only privileged users to load eBPF programs, the verifier also had to account for the unique nature of Tolkien Ring itself. eBPF may be Turing complete, but Tolkien Ring demanded something even stricter, Fate complete. Mutable state is forbidden, once a value is set, it can never be changed, for the past cannot be rewritten. Tolkien Ring also does not “retry” packets, if a message failed to arrive, it was simply never meant to be. The verifier had to enforce this logic, rejecting any program that attempted to interfere with the will of the network.

Beyond the existing loader libraries for languages like Go, Rust, and Java, new ones had to be written for the ancient tongues Elvish, Dwarvish, and even the Black Speech of Mordor. Parsing rune encoded eBPF instructions proved particularly challenging, as some scripts changed meaning depending on the phase of the moon. The JIT compiler also had to be extended to translate these arcane instructions into efficient machine code while preserving their original intent. Miscompiling a single rune could turn a simple forwarding program into a summoning ritual! Luckily, as one of the fastest-moving subsystems of the kernel, the eBPF community proved up to the challenge.

“This project is a testament to the power and flexibility of eBPF not just to build the future, but to rebuild the past, better than before,” said Thomas Graf, Chair of the eBPF Foundation and VP Isovalent at Cisco. “We’re seeing a shift across the industry as people look for alternatives to legacy platforms, and eBPF is proving to be the perfect tool for modernizing old systems without being constrained by their original limitations. Whether it’s replacing outdated networking and orchestration stacks or resurrecting protocols once thought lost to time, eBPF allows us to innovate while still honoring and leveraging the foundations of the past.”

Of course, simply restoring Tolkien Ring wasn’t enough. It had to be optimized for modern workloads. Traditional implementations relied on hand-etched routing tables, often inscribed in stone or passed down through oral tradition, making updates slow and error-prone. With eBPF, these routing decisions can now be dynamically updated in real time, adapting to changing network conditions while maintaining the protocol’s original intent. Early benchmarks show a 300% increase in message throughput, though some wizards argue this is merely the will of the Valar.

As always, the eBPF community remains committed to pushing the boundaries of what’s possible whether in the modern cloud native era or the forgotten networks of the First Age. Because eBPF is One bee to rebuild Tux, one JIT to run them, one verifier to judge them all, and in the kernel bind them.

Where to learn more about eBPF:

What If CI/CD Pipelines Had Built-in Security and Observability with eBPF?

Thu, 27 Mar 2025 09:55:00 GMT

Learn how eBPF can add real-time security and observability to CI/CD pipelines like GitHub Actions, helping detect exploits and optimize workflows execution time.

Case Study: Polar Signals Uses eBPF to Monitor Internal Cross-Zone Network Traffic on Kubernetes, Reducing These Operating Costs by 50%

Thu, 16 Jan 2025 09:55:00 GMT

Polar Signals developed kubezonnet, an open source project designed to monitor and measure cross-zone network traffic in Kubernetes clusters. The solution leverages eBPF to trace network packets and aggregate traffic data.

Tracepoints, Kprobes, or Fprobes: Which One Should You Choose?

Sat, 04 Jan 2025 09:55:00 GMT

Tracing programs like kprobes, fprobes, and tracepoints are very popular, but their overlapping functionality can make choosing the right one confusing.

eBPF in 2025 - Bigger Than the CrowdStrike Outage

Wed, 01 Jan 2025 12:33:00 GMT

In 2025 eBPF adoption will expand rapidly and other predictions

P99Conf: How eBPF Could Make Faster Database Systems

Sun, 27 Oct 2024 17:00:00 GMT

Learn about BPF-DB, an in-memory key-value data store that can be planted within the OS kernel itself via eBPF, thereby routing around the restrictions and limitations of an OS’s user space, or the space in memory where a program is typically run