Community Blog The Advantages and Disadvantages of eBPF

The Advantages and Disadvantages of eBPF

This article introduces Extended Berkeley Packet Filter (eBPF) technology and explains its advantages and disadvantages.


With the popularization of Extended Berkeley Packet Filter (eBPF) technology in various industries, people are enjoying the dividends of technological change while also suffering from pervasive malicious attacks; everything has two sides. No technology has advantages without disadvantages. Only a clear analysis of the kernel of eBPF can drive it forward and avoid the disadvantages so it can play as positive a role as possible.

What are the advantages and disadvantages of eBPF?

Increasingly Tough Linux Security Situation

According to the Enterprise Strategy Group (ESG) Research Report on Cloud-native Security, 88% of cybersecurity professionals said their cloud-native applications and infrastructure had been attacked in the past 12 months. However, many cloud security solutions designed to protect Linux are cumbersome and disruptive because they are ported from Mac or Windows operating systems. Sometimes, these solutions impair the processing capacity of the Linux system or even make changes.

Most solutions are based on lightweight agents, which minimize any possible performance impact and extend MDR to the local system and the cloud. These solutions are often built with automated rule-based response and analysis features (such as SanerNow, Automox, Cybereason, Syxsense Secure, Sangfor Endpoint Secure, etc.), with the following characteristics:

  1. Watch activity data from endpoints that may imply a threat
  2. Evaluate data to determine threat patterns
  3. Automatically respond to identified threats to eliminate or contain them and notify security personnel
  4. Use forensic and analytical tools to study identified threats and look for suspicious activity

Currently, more stringent requirements on EDR and XDR products are put forward in the Linux environment:

  1. Linux threat and attack vectors are different from their Windows/macOS counterparts and require a separate strategy.
  2. Linux is usually the foundation of production systems, and the interruption or interference of the product should not have a negative impact on the business.
  3. Build a lightweight Linux EDR sensor for the building and optimization of Linux to minimize the impact on the system.


Linux-Based Cloud-Native Infrastructure

The combination of cloud-native applications consists of the APIs, containers, VMs, and Serverless features of CI/CD. Protecting these applications, the underlying infrastructure, and the automated platform that coordinates their deployment requires revisiting the threat patterns, gaining organizational consistency, and leveraging purposeful controls. In addition, as security and DevOps continue to converge, cloud security control is being integrated. Developing isolated approaches into a unified strategy to protect cloud-native applications and platforms is a shared goal of many security vendors currently. It is also a real need for Party A. At the same time, more security vendors are trying to integrate cloud security posture management (CSPM), cloud workload protection (CWP), container security, and other solutions into the integrated cloud security suite to increase the competitiveness and voice of their security products in the market and avoid the fragmentation of security products.


The cloud-native infrastructure includes CPU hardware, instruction set, operating system, etc., which enhances the high performance and security of the operating system. It is also an area eBPF technology is currently exploring. Therefore, the security capability of the eBPF technology is also an important indicator to test whether the technology is sustainable.


The Disadvantages of eBPF

eBPF has seen much popularity in the Linux world. It was introduced in 2013 to support programmable networks and is now used for observability, security, networking, etc. Many major companies, including Meta, Google, Microsoft, and Netflix, are committed to helping develop and support it, especially in the cloud-native field. Note: eBPF and BPF are synonymous. The community often uses these two terms interchangeably, in part because eBPF has almost completely replaced the classic BPF technique.

In the past few years, unlicensed organizations have been studying to develop Linux malware and expand the negative role of Linux malware by using eBPF. Security researchers are constantly fixing vulnerabilities and trying to predict the 0-day vulnerability in advance. Recently, some examples of eBPF-related CVE reports frequently appear in top-level security conferences (such as DEFCON and BlackHat), which makes people pay more attention to and worry about the security of eBPF. I will gradually translate and verify the following topics and share them synchronously:

Now let's take a deeper look at the eBPF mechanism and see how hackers can use these powerful features to achieve their goals.

  • bpf_probe_write_user

Utility: An eBPF program has access to a limited set of helper functions built into the kernel. A helper for malicious exploitation of eBPF is bpf_probe_write_user. This function allows the eBPF program to write to the user-space memory of the currently running process. This capability, if exploited maliciously, can modify the process memory during system calls (such as bad-bpfsudo), which writes to user-space memory /etc/sudoers while reading. It injects an extra code that allows a specific user to use the sudo command.


(1) If the memory is swapped out or not marked as writable, the function will fail.

(2) A warning message is printed to the kernel log to indicate that the function is being used. This is to warn the user that the program is using a potentially dangerous eBPF helper function.

  • bpf_override_return

Utility: bpf_override_return, another eBPF helper function, allows the program to override the return value. Hackers can use it to stop malicious exploitation. For example, if you want to run kill -9, a hacker can attach kprobe to the appropriate kernel function to process the kill signal, return an error, and effectively prevent the system calls from occurring. It is used by the open-source project ebpfkit to block operations that could lead to the discovery of user-space processes that control the eBPF program.


(1) Open the option during kernel building: CONFIG_BPF_KPROBE_OVERRIDE

(2) Currently, only x86 is supported.

(3) It can only be used with kprobes.

  • XDP and TC

Utility: ebpfkit uses XDP and TC for implicit communication. The following image is from the presentation of the Blackhat Briefings where the developers of ebpfkit (Guillaume Fournier, Sylvain Afchain, and Sylvain Baubeau) outlined how to use XDP and TC to hide the commands sent to ebpfkit and how the XDP program running on the host receives and processes the requests. The program identifies this as a request to a malicious exploitation running on the host and modifies the packet as a normal HTTP request to a web application running on the host. At the exit, ebpfkit uses the TC program to capture the response from the web application and modify its output with the response data from ebpfkit.


(1) The XDP program runs too early, and the data has nothing to do with the process or socket, so there is almost no context around the packet.

Image source: https://www.blackhat.com/us-21/briefings/schedule/index.html#with-friends-like-ebpf-who-needs-enemies-23619

The Advantages of eBPF

The core of eBPF is an instruction set architecture (ISA) that can run in a VM-like structure in the Linux kernel, with registers, instructions, stacks, etc. In order to use eBPF, users can create eBPF programs and attach them to the appropriate places in the system, usually in the kernel. When the event associated with the attach point occurs, the program runs and has the opportunity to read the data from the system and return the data to the control application in user space. In summary, eBPF allows users to dynamically install code executed in the context of the kernel but can be programmed from user space. It is kind of like a hybrid between user-space applications and Linux kernel modules.


It is unnecessary to repeat the basic knowledge of eBPF since there are already too many tutorials and analysis articles on the Internet. I suggest beginners learn the development history of eBPF from the official website or directly learn and verify it in specific source code examples of the kernel. While eBPF provides convenience for many Linux kernel developers, it also provides new technologies for malware developers.

The following diagram summarizes the entire lifecycle of an eBPF program:


Security Benefits:

  1. Socket filters are the original use case for classic BPF. A socket filter is an eBPF program that can be attached to a socket. The program can filter incoming traffic for that socket. The name of the Berkley Packet Filter implies that it is a technology designed to filter packet data. This function has been retained in modern eBPF.
  2. ByteCode eBPF programs can be written in restricted C. Restricted means that the stack size, program size, loops, and available functions are limited compared to normal C programs. The C code is compiled into eBPF bytecode.
  3. Before the eBPF code is completely loaded into the kernel, the verifier will run through the validator. The work of the verifier is to determine whether the eBPF program can run safely. Safe means that the eBPF program will not fall into an infinite loop, there are no unsafe memory operations, and the program is below the maximum complexity/code size.

Security Policy:

1.  Ensure that unprivileged eBPF is disabled. Today, you usually need a root or at least CAP_SYS_ADMIN and/or CAP_BPF to install the eBPF program. This is not always the case. Unprivileged eBPF is introduced in kernel 4.4. Be sure to check this configuration option by running the following command:

sysctl kernel.unprivileged_bpf_disabled

2.  Disable any unwanted features. Administrators can programmatically disable things like kprobes:

echo 0 > /sys/kernel/debug/kprobes/enabled

3.  Build a kernel without support for kprobes, eBPF-based TC filters, or with full support for eBPF (although this may not be an option for many people).

4.  Do not set ONFIG_BPF_KPROBE_OVERRIDE to Ensure unless absolutely necessary.

Security Detection:

From the perspective of the security cycle, detection is divided into three major stages: before (before run time), during (during run time), and after (after an attack). Security personnel all hope that they can detect anomalies through a series of static analysis methods before run time to eliminate the problem before it occurs. However, the reality often backfires. More anomaly detection occurs at run time. At this time, the product model designed by security personnel is required to have a strong anomaly detection ability, which determines the success of the final solution.

Look at the specific solution from the dimension of eBPF and Linux Tracing:

1.  Look for unexpected kprobes loaded:

#cat /sys/kernel/debug/kprobes/list
ffffffff8ad687e0 r ip_local_out+0x0 [FTRACE]
ffffffff8ad687e0 k ip_local_out+0x0 [FTRACE]

2.  Use bpftool to list the programs using eBPF in the system:

# bpftool prog
176: cgroup_skb tag 6deef7357e7b4530 gpl
loaded_at 2022-10-31T04:38:09-0700 uid 0
xlated 64B jited 54B memlock 4096B
185: kprobe tag a7ce508aab49e47f gpl
loaded_at 2022-10-31T10:03:16-0700 uid 0
xlated 112B jited 69B memlock 4096B map_ids 40
# bpftool perf
pid 543805 fd 22: prog_id 3610 kprobe func tcp_v4_connect offset 0
pid 543805 fd 23: prog_id 3610 kprobe func tcp_v6_connect offset 0
pid 543805 fd 25: prog_id 3611 kretprobe func tcp_v4_connect offset 0
pid 543805 fd 26: prog_id 3611 kretprobe func tcp_v6_connect offset 0
pid 543805 fd 28: prog_id 3612 kretprobe func inet_csk_accept offset 0

3.  Find the loaded XDP program:

$ ip link show dev <interface>
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 xdpgeneric qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
prog/xdp id 220 tag 3b185187f1855c4c jited

4.  Check if there are any pinned objects in the BPF file system (bpffs):

$ mount | grep bpf
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
#ls -la /sys/fs/bpf/

5.  Check if any TC program is loaded:

#tc filter show dev <device-name>

6.  Monitor whether the warning message generated by the BPF helper function is mentioned in the system log:

#dmesg -k | grep ‘bpf_probe_write_user’


In short, eBPF has become a powerful tool for security researchers and hackers. The result it brings depends on the user's choice. This paradigm shifts the ways and processes used to implement malicious exploitation in the past. It also raises the demand for security personnel to study and understand cutting-edge technologies and the exploitation of emerging threats.

As we continue to analyze and understand how to identify and detect the malicious abuse of eBPF, we will have a deeper understanding of the principles of such malicious exploitation, its way of action, and the best way to detect it. The follow-up research and analysis will be shared continually.

eBPF Research SIG homepage: https://openanolis.cn/sig/ebpfresearch

About Author

Qingwei Xu (Maintainer of eBPF Research SIG at OpenAnolis and Senior Kernel Technology Expert) has in-depth research background on Linux kernel and system stability.

0 2 1
Share on


84 posts | 5 followers

You may also like