Introduction
eBPF (extended Berkeley Packet Filter) is a successor to the BPF (Berkeley Packet Filter) which already existed as part of the Linux kernel as far back as 1992. It allows developers to safely extend the kernel based on sys-call events, and gives developers the ability to see network packets coming into the kernel space, as well as hook into processes running in the user space.
XDP (eXpress Data Path) is a suite of eBPF hooks in the network layer of the Linux Kernel which allow developers to decide what happens to network packets in an eBPF program.
Since their creation, eBPF and XDP have made it possible to create much simpler and more performant new methods for implementing observability, networking and security features for the processes which run on containers across thousands of servers in a typical data center. These simpler new methods are much more efficient than the standard practice of sidecar loading Therefore, it is very valuable for developers looking to implement observability, networking or security features on a linux server to learn how eBPF and XDP work, and take advantage of the ease of use and performance advantages they offer.
Why choose C for eBPF and XDP
The Linux kernel is written in C, offering minimal overhead compared to other frameworks.
The Linux kernel and its virtual-machine-like BPF facility for executing eBPF bytecode are written in C. The kernel's BPF hooks which allow eBPF programs to be attached to specific points in the kernel execution path are provided as kernel interfaces defined in C. Plus, third-party eBPF helper libraries such as libbpf, and freely available XDP tutorials are also written in C. So choosing C to write your eBPF programs is a no-brainer, especially when using C offers minimal overhead compared to other frameworks and provides direct access to hardware resources.
Excellent option for low-level programming which is where eBPF and XDP shine
eBPF VMs, running within the Linux kernel, intercept and modify network packets at a very low level. This allows them to directly access network packets in memory. This direct memory access makes eBPF significantly faster and more efficient than traditional methods for processing network traffic. By writing eBPF programs in C, developers can take advantage of this direct memory access, ensuring your programs efficiently manipulate network packets and achieve maximum performance.
What will the reader learn in this article?
In this article you will learn:
1. Where eBPF and XDP sit in the Computing Stack
2. The Lifecycle of an eBPF Application
2.1. Source Code
2.2. Compiled Object File
2.3. Open Phase
2.4. Load Phase
2.5. Attachment Phase
2.6. Execution
2.7. Tear Down Phase
3. How to Build a Simple Packet Filter with eBPF and XDP
3.1. Setup the Development Environment
3.2. Write a packet filtering eBPF program
3.3. CO-RN compile the packet filter
3.4. Inspect the compiled BPF object file
3.5. Load and attach the BPF program to a network device
3.6. Inspect the running BPF program
3.7. Detach and unload the packet filter
All exercises are run via ssh on a Ubuntu 24.04.1 LTS (GNU/Linux 6.8.0-45-generic x86_64)
Building a Simple Packet Filter with eBPF and XDP
Task 1. Understand Where eBPF and XDP run in the Computing Stack
Image showing where eBPF programs run in the Linux Computing Stack
Image showing where XDP sits in the Linux Networking Stack
Task 2. Understand The Lifecycle of an eBPF and XDP Application
1. Source Code: C code which includes eBPF-specific constructs, XDP hooks, libbpf APIs, and eBPF helpers.
2. Compiled Object File: BPF object file created from C code, often using CO-RE (Compile Once – Run Everywhere) for kernel version portability.
3. Open Phase: The user space program calls libbpf functions like bpf_object__open() or <name>__open() (for skeletons). These functions parse the BPF object file, discover maps/programs/variables, and allow for preload adjustments.
4. Load Phase: The user space program calls libbpf functions like bpf_object__load() or <name>__load() (for skeletons).These functions interact with the kernel via system calls to create BPF maps, resolve relocations, verify and load programs into kernel, and setup initial map states.
5. Attachment Phase: The user space program calls attachment functions, either directly with libbpf APIs or via <name>__attach() for auto-attachable programs in skeletons. For manual attachment, specific libbpf functions like bpf_program__attach() are used to attach BPF programs to specific kernel hook points (e.g., tracepoints, kprobes, network interfaces).
6. Execution: Attached programs run in kernel, processing data (e.g., network packets), updating maps, and modifying variables accessible from user space.
7. Tear Down Phase: When the BPF application is shutting down the user space program typically calls libbpf functions like bpf_program__detach() for individual programs, or <name>__destroy() for skeletons. It detaches eBPF programs from hook points, unloads from kernel, destroys maps, and frees all associated resources to avoid resource leaks.
For more on libbpf APIs or BPF Object Skeletons, please see The Linux Kernel libbpf Overview
Task 3. Build a Simple Packet Filter with eBPF and XDP
To be continued …