# Dynamic Fixed-point Values in eBPF: a Case for Fully In-kernel Anomaly Detection

Atsuya Osaki, Manuel Poisson, Seiki Makino, Ryusei Shiiba, Kensuke Fukuda, Tadashi Okoshi, Jin Nakazawa

► To cite this version:

Atsuya Osaki, Manuel Poisson, Seiki Makino, Ryusei Shiiba, Kensuke Fukuda, et al. Dynamic Fixed-point Values in eBPF: a Case for Fully In-kernel Anomaly Detection. aintec, Aug 2024, Syndey, France. 10.1145/3674213.3674219. [hal-04967351](https://hal-inria HAL Id: hal-04967351)

https://inria.hal.science/hal-04967351v1

Submitted on 26 Feb 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
<figure><img src="image_2.png" /></figure>

# Dynamic Fixed-point Values in eBPF: a Case for Fully In-kernel Anomaly Detection

Atsuya Osaki
atsuyao@keio.jp
Keio University
Kanagawa, Japan

Manuel Poisson
manuel.poisson@irisa.fr
CentraleSupélec, Inria
Rennes, France

Seiki Makino
kino-ma@sfc.wide.ad.jp
Keio University
Kanagawa, Japan

Ryusei Shiiba
siiba@nii.ac.jp
Sokendai
Kanagawa, Japan

Kensuke Fukuda
kensuke@nii.ac.jp
NII/Sokendai
Tokyo, Japan

Tadashi Okoshi
slash@sfc.keio.ac.jp
Keio University
Kanagawa, Japan

Jin Nakazawa
jin@sfc.keio.ac.jp
Keio University
Kanagawa, Japan

## ABSTRACT

eBPF and XDP are promising technologies that are capable of accelerating packet processing inside the Linux kernel. Despite these benefits, eBPF is constrained by a number of rigorous restrictions that are imposed to protect the kernel. One such restriction is the lack of support for floating-point values, which was introduced to achieve faster execution and avoid non-deterministic behavior. However, this has become a significant obstacle to expanding the functionality of eBPF programs with advanced algorithms. In this paper, we propose dynamic fixed-point as a solution to overcome this challenge within the restrictions of eBPF. Dynamic fixed-point values are an expansion from traditional fixed-point values, with the bit allocation adjusted dynamically. Benefit of dynamic fixed-point is that the accuracy of calculations are improved, which is one of the critical shortcomings of fixed-point. To demonstrate the effectiveness of our approach, we have designed and implemented a prototype of an entropy-based traffic anomaly detection framework and have reported on its throughput and the detection accuracy. Our prototype, which employs dynamic fixed-point, has achieved an 18% improvement in throughput while also matching the detection accuracy of a similar system that employs floating-point values in user space.

## CCS CONCEPTS

* Software and its engineering → *Designing software*; 
* Security and privacy → *Intrusion/anomaly detection and malware mitigation*; 
* Denial-of-service attacks.

## KEYWORDS

eBPF, XDP, Anomaly Detection, DDoS, Dynamic Fixed-point

## ACM Reference Format:

Atsuya Osaki, Manuel Poisson, Seiki Makino, Ryusei Shiiba, Kensuke Fukuda, Tadashi Okoshi, and Jin Nakazawa. 2024. Dynamic Fixed-point Values in eBPF: a Case for Fully In-kernel Anomaly Detection. In *ASIAN*

INTERNET ENGINEERING CONFERENCE 2024 (AINTEC '24), August 09, 2024, Sydney, NSW, Australia. ACM, New York, NY, USA, 9 pages. https://doi.org/10.1145/3674213.3674219

## 1 INTRODUCTION

Since the introduction of eBPF (extended Berkeley Packet Filter) [16, 29], it has gained popularity as a solution for implementing new features into the Linux kernel. There are numerous applications of the technology [10, 11, 19, 20, 26, 27, 32]. Nevertheless, the capabilities of eBPF programs remain constrained by the security requirements of eBPF, impeding the implementation of advanced algorithms within eBPF. The most significant limitations pertain to the size of programs, the use of loops, and the inability to utilize floating-point values.

The researchers and the community have poured huge effort to ease the restrictions on eBPF programs. The limitation on the program size was alleviated with the introduction of tail calls in the Linux kernel 4.2 [3]. While this enhanced the capabilities of eBPF programs, it was further improved in the Linux kernel 5.2 when the allowed number of instructions per eBPF program was increased [2]. The allowed number of instructions were increased from 4096 to one million, allowing for much more complex eBPF programs to be developed. Additionally, bounded loops were allowed with Linux kernel 5.3, opening a new gate for further advancements [5]. However, some restrictions remain, namely the incapability to use floating-point values. In general, the use of floating-point values is avoided within the kernel space, as the register values are not saved during context switches due to the additional overhead. However, the ability to calculate decimal point values is crucial in modern programs, and the inability to use floating-point values limits the possible workloads.

This paper discusses the use of dynamic fixed-point values within eBPF programs to emulate floating-point values. One disadvantage of fixed-point values is their lower precision compared to floating-point values. To mitigate this limitation, we leverage the dynamic fixed-point approach, which dynamically adjusts bit allocation during the calculation (subsection 4.1). To illustrate the benefits of our approach, we implemented a prototype framework for anomaly detection using dynamic fixed-point (subsection 4.2). We discuss the design choices made for this prototype, with a particular focus on the following aspects: (1) the use of dynamic fixed-point values and the implementations of its basic arithmetic operations (2) our

<footnote>Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for third-party components of this work must be honored. For all other uses, contact the owner/author(s).

AINTEC '24, August 09, 2024, Sydney, NSW, Australia

© 2024 Copyright held by the owner/author(s).

ACM ISBN 979-8-4007-0985-2/24/08

https://doi.org/10.1145/3674213.3674219</footnote>
choice to employ fast entropy approach for the anomaly detection technique, primarily to achieve higher overall performance of the framework. The prototype demonstrated an 18% improvement in throughput compared to the user space + eBPF counterpart, while maintaining the same level of detection accuracy (section 5).

The contribution of this paper is as follows: (1) we introduce the implementation of dynamic fixed-point which expands the capabilities of eBPF programs (2) we demonstrate that fully in-kernel implementation has 18% higher throughput than typical user space + eBPF implementations and 55% higher in memory-intensive workloads (3) we demonstrate that the dynamic fixed-point values are capable of matching the detection accuracy of floating-point values (4) we discuss the feasibility of fully in-kernel anomaly detection and organize the cases that would benefit from moving workloads from user space to eBPF programs.

# 2 BACKGROUND

In this section, we explain the underlying technologies and concepts used in our work.

## 2.1 eBPF and XDP

eBPF [16, 29] is a virtual machine environment within the Linux kernel that is capable of executing byte code that has been converted from user-defined code. In general, eBPF programs are written in restricted C language, which gets converted to special byte code by the Clang/LLVM. This byte code is compiled just-in-time upon execution into native machine language, which contributes to the high performance of eBPF programs. The verifier, a mechanism that analyzes the program source code at the time of injection into the kernel, verifies that the program is safe for execution through the check for turing-completeness and memory sanity. While these checks affirm the safety of eBPF programs, they are also a direct reason to many eBPF-related restrictions. The execution of eBPF programs are totally event-driven, and the events are specific to each hook point of the program. Consequently, eBPF programs must store the context to BPF Maps, a key-value store on the kernel memory, in case they want to carry over any context to the next execution. The semantics of the key-value stores are pre-defined, and a few examples are arrays, hash maps, and ring buffers. Libbpf [4] is a library that aims to facilitate the development of eBPF programs such that it provides functions for loading/unloading of eBPF programs, accessing BPF Maps, and other helper functions to ease the implementation of user space and eBPF programs.

eXpress Data Path (XDP) [18] is a hooking point for eBPF programs to capture, process, and modify packets at high speed. XDP allows eBPF programs to be executed in the NIC device driver, which is the earliest point of access to the packets. Because the device driver is prior to resource-intensive tasks inside the kernel, XDP is able to achieve fast packet processing. XDP has the ability to instruct the NIC device driver to either transmit the packet to the Linux kernel, discard the packet, redirect the packet from the same NIC, redirect the packet from a different NIC, or bypass the Linux kernel to transfer the packet data to a user-space program.

## 2.2 Fixed-point values

Fixed-point values is a way to represent decimal point values as integer values. It stores real numbers inside the memory with a fixed binary point. This is popular in the field of embedded systems for the representation and calculation of real numbers. In fixed-point, we divide the specified data length into sections, integer part and fractional part, in addition with the sign part if we wish to handle signed numbers.

$$3.625 = 0b11.101 = 1 \times 2^1 + 1 \times 2^0 + 1 \times 2^{-1} + 0 \times 2^{-2} + 1 \times 2^{-3} \quad (1)$$

Let us consider the case with Equation 1, where we wish to store 3.625 into an eight-bit data length, with the bit allocation of four bits each for the integer part and the fractional part. In order to convert real number to a fixed-point value, we bit shift four times (the number of bits for the fractional part) to the left. This operation multiplies the value by eight, moving the binary point by four digits. Thus, the number is now represented as 0b111010, or 29, and the fraction part of the original value is represented inside the integer part.

The bit allocation is determined by the coder of each fixed-point implementation, taking into account the risk of arithmetic overflow and desired precision. Unfortunately, it is not always possible to predict the optimal balance between the two. Moreover, precision loss is critical in many programs. Therefore, floating-point values are used in scenarios with CPUs that have Floating-Point Units (FPU). Despite these demerits, fixed-point values have been used in embedded systems where their CPU does not have an FPU.

For the sake of differentiation between traditional fixed-point and dynamic fixed-point, we call the former static fixed-point. When we refer to fixed-point values, we mean both the static fixed-point and dynamic fixed-point values.

We use Q notation [6] to represent the bit allocation of static fixed-point. In Q notation, bit allocation of static fixed-point is expressed as $Qx.y$. The x and y represent the number of integer bits and that of fractional bits respectively. For example, Q7.25 represents that seven bits are allocated for the integer part and 25 bits for the fractional part.

# 3 CHALLENGES IN IN-KERNEL PROCESSING

Despite the benefits and capabilities of eBPF, there are four limitations that become a critical challenge to implementing complex algorithms within eBPF programs.

**No unbounded loops.** Unbounded loops are prohibited in kernel programming, as it would lock the CPU. eBPF programs follow the same rule. Although bounded loops have been supported since the release of Linux kernel 5.3 [5], many machine learning models require unbounded loops, which causes difficulties for some machine learning models to pass the verification.

**Maximum instruction count.** eBPF programs of sizes under one million instructions can only pass the verification. As we discussed in subsection 2.1, the verifier analyzes the program source code to test its turing-completeness. The test is a depth-first and width-first check of up to one million instructions. If the verifier is unable to exit the program after one million instructions, the program is rejected. The limit on instruction count defines the possible complexity of eBPF programs and the algorithms used
inside it. Algorithms such as unsupervised machine learning and neural networks tend to have higher complexity, increasing the chance to reach this instruction count limit. The workaround is to use tail call in a chained manner, a way to execute other eBPF programs from an eBPF program. By splitting lengthy workloads into multiple eBPF programs, it is then possible to avoid reaching the maximum instruction count. However, the maximum chained tail calls allowed is 32, which implies that a hard limit exists.

**Restricted memory access.** The verifier restricts memory access outside of local variables, program arguments, and BPF Maps, in order to protect the kernel. Therefore, if a program requires any input, it must be handed through program arguments or BPF Maps. For example, XDP, a hooking point for eBPF programs that facilitate rapid packet processing, can hand packet bytes to the program through its program argument. BPF Maps are used for the purpose of sharing data between eBPF programs or to pass input from user space.

**No floating-point values.** eBPF does not support floating-point values, which is crucial in many advanced algorithms, such as machine learning. This exclusion of support is because floating-point arithmetic are non-deterministic in such that the results may vary between CPU architectures. Therefore, libraries and functions that rely on floating-points, such as `math.h`, cannot be used inside eBPF programs, imposing a major challenge to implementing any algorithms that depend on them.

# 4 DESIGN AND IMPLEMENTATION

We propose the use of dynamic fixed-point values to expand the capabilities of eBPF programs. There are performance benefits from moving workloads from user space to eBPF programs as it reduces the number of context switches and memory copies. However, eBPF-related restrictions present a significant challenge to implementing advanced algorithms inside eBPF programs. We focus on providing the solution to the most critical restriction, namely the lack of support for floating-point values, and propose the use of dynamic fixed-point values. To demonstrate the effectiveness, we implement a prototype of an anomaly detection/mitigation framework using the proposed method. We also provide explanation about the system architecture, workarounds to other eBPF-related restrictions, and the anomaly detection technique.

## 4.1 Dynamic fixed-point

We propose the use of fixed-point values, especially dynamic fixed-point as a replacement of floating-point values. Fixed-point values enable the use of integer arithmetic to emulate floating-point values inside eBPF programs with a cost of lower accuracy. The accuracy of calculation depends on the bit allocation and the number to be calculated. The problem is that we do not always know the best bit allocation. If we allocate more bits for the integer part, precision of the fractional part is lost. If we do the opposite, there is a higher chance to experience arithmetic overflow. To avoid this, we propose the use of dynamic fixed-point, which dynamically adapts the bit allocation to minimize the arithmetic error.

We use 40-bit data length to store dynamic fixed-point values and implement each arithmetic operation. The first 32-bits of the 40-bits data length is used for storing the number and is separated

<table><caption>**Table 1: Number of instructions.**</caption><thead><tr><th>Function</th><th>Instruction count</th></tr></thead><tbody><tr><td>Addition func</td><td>56</td></tr><tr><td>Subtraction func</td><td>56</td></tr><tr><td>Multiplication func</td><td>43</td></tr><tr><td>Division func</td><td>51</td></tr><tr><td>Logarithm func</td><td>60</td></tr><tr><td>Absolute value func</td><td>5</td></tr><tr><td>Header parsing and logging</td><td>155</td></tr><tr><td>Packet filtering</td><td>27</td></tr><tr><td>Anomaly detection</td><td>580</td></tr><tr><td>Whole framework</td><td>762</td></tr></tbody></table>

**Algorithm 1: min_number_of_integer_bits.**

**Input:** Single dynamic fixed-point value *fp*

**Output:** Minimum number of bits to represent *fp*

1 **Function** min_number_of_integer_bits(*fp*):

2 &nbsp;&nbsp;&nbsp;&nbsp; sig_bit ← binary_search_most_significant_bit(*fp*)

3 &nbsp;&nbsp;&nbsp;&nbsp; total_bits ← sizeof(*fp*) × 8

4 &nbsp;&nbsp;&nbsp;&nbsp; sign_bit ← 1

5 &nbsp;&nbsp;&nbsp;&nbsp; return total_bits - sign_bit - sig_bit

into sections for the sign, integers, and fractional part. The remaining eight bits are allocated to store the bit allocation. The default bit allocation for our dynamic fixed-point implementation is Q7.24, with a single bit reserved for the sign. The bit allocation changes when (1) conversion from integer to dynamic fixed-point happens (2) arithmetic overflow happens. We implement the basic arithmetic operations, addition, subtraction, division, multiplication, absolute values, and logarithms. For logarithms, we estimate the value using bit shifting and pre-prepared tables, to reduce the instruction count. We share the instruction count for each arithmetic operation in Table 1.

### 4.1.1 Tracking the largest number.
In our implementation, the initial bit allocation is determined by the largest integer value used in the calculation. This avoids any arithmetic overflow while fully utilizing the available bits. To achieve this, we must track the largest integer number that would be later converted into dynamic fixed-point value. When we increase an integer number, we use the following to determine whether the number would cause overflow with the current bit allocation:

$$i < (1 \ll (x - 1)), \qquad (2)$$

where *i* represents the integer number, and *x* is the number of integer bits. We subtract one from *x* to leave a bit for the sign. If this equation is not true, it is an indication to increase the number of integer bits. We use Algorithm 1 to find the new number of integer bits. The algorithm finds the most significant bit of the number through a binary search, and determines the minimum number of bits required to represent that number. Then, we update the bit allocation according to the returned value of this function.
<figure><img src="image_3.png" /><figcaption>**Algorithm 2: Multiplication.**</figcaption></figure>

4.1.2 *Avoiding Arithmetic overflow.* We avoid arithmetic overflow by allocating abundant amount of data length during the calculation. Since the bit allocation is determined by the numbers to be calculated, arithmetic overflow happens in situations where the results of the calculations are larger than the values to be calculated. To avoid this, we allocate 64-bits of data length during the calculation, and if an overflow of the integer part is expected with the current bit allocation, we increase the number of integer bits to fit the most significant bit inside the 32-bit data length. Precision of the fractional part may be lost during this re-allocation.

We explain our approach using the implementation of multiplication as an example. Algorithm 2 is the pseudo-code of its algorithm. We start by separating the dynamic fixed-point values into sections of upper 16-bit and lower 16-bit (lines 2-5). Then, we multiply the upper 16-bit of the two numbers, which contains the most significant bit of the final product. If the product of the upper 16-bit cause overflow with the current bit allocation, we use Algorithm 1 to find the minimum number of integer bits that can represent this value (lines 6-8). Finally, after we found the new bit allocation, we multiply each section, upper and lower 16-bits, with the section with the other number to find the final product (lines 10-12).

## 4.2 Case study: Anomaly detection

As an application of dynamic fixed-point values, we implement a fully in-kernel anomaly detection/mitigation framework.

<figure><img src="image_4.png" /><figcaption>**Figure 1: Difference in architecture.**</figcaption></figure>

4.2.1 *Overview of the System Architecture.* Figure 1 portrays the difference in architecture of the typical eBPF + user space implementation (Figure 1a) and the proposed fully in-kernel implementation (Figure 1b). The workflow of both implementations are as follows: (1) packet arrives at the eBPF program (2) packet is either accepted or declined according to the filter settings (3) log data of the accepted packet is stored in the database (4) the packet is forwarded from a different NIC. After a certain interval time has passed, the log data is passed to the anomaly detection program to be processed. If an anomaly is detected, a new filter setting is created and saved to the database to be read by the filtering program. The instruction count of each function of the framework is shown in Table 1. The instruction count of the whole framework is well-contained inside the one million limitation.

The database is in fact a group of different BPF Maps. The event-driven nature, execution per packet arrival, makes it impossible to carry over variable data between exections. We cannot store data inside the memory either, as eBPF restricts memory access. To work around this, we use BPF Maps to restore context data between execution of the framework. Log data, such as packet count per flow, is stored inside a BPF Map with hash map structure. Filter settings are stored inside a BPF Map with trie tree structure, and arbitrary context data, such as total packet count, detection threshold, and bit allocation, are stored inside an array type BPF Map. When we need to recursively read and update the data from the BPF Maps, we use bpf_map_forEach_elem() function from libbpf. This avoids the use of loops inside the fully in-kernel implementations, working around another eBPF-related restriction.

4.2.2 *Implementation of Anomaly Detection.* We perform the anomaly detection using the statistics-based approach. The recent approaches to anomaly detection can be categorized into three main groups: statistics-based (entropy-based) [13, 15], machine learning based [7, 23], and neural network based [21, 31]. While neural network approach and machine learning approach tend to be favored in terms of detection accuracy and flexibility, statistics-based approach has its strengths in processing speed, due to its less compute-intensive nature. To maximize the benefit of using a fast data plane, XDP, we chose to perform the anomaly detection with the statistics approach. Although we stick to the statistics approach, anomaly
detection technique is independent from the system architecture, and thus other techniques can be implemented into our framework.

Out of many techniques for numerous statistics approaches, we chose to use the fast entropy-based approach [13, 22]. The fast entropy approach is a simplified entropy calculation method that approximates the entropy values. Due to the approximation, it is even less compute-intensive compared to other entropy-based approaches. The runtime of conventional entropy is $O(n^2)$, where it is $O(\log n)$ for the fast entropy approach [22]. The fast entropy approach is defined as follows:

$$H_{(i,t)} = -\log \frac{x_{(i,t)}}{\sum_{i=1}^{n} x_{(i,t)}} + \tau_{(i,t)} \quad (3)$$

$$\tau_{(i,t)} = \begin{cases} \left| \log \frac{x_{(i,t+1)}}{x_{(i,t)}} \right|, & x_{(i,t)} \ge x_{(i,t+1)} \\ \left| \log \frac{x_{(i,t)}}{x_{(i,t+1)}} \right|, & x_{(i,t)} < x_{(i,t+1)}. \end{cases} \quad (4)$$

We calculate $H_{(i,t)}$ for each flow and get an average value, where $x_{(i,t)}$ is packet count from the flow i, for the interval t. We compare the average value and $H_{(i,t)}$ of each flow. If the difference is greater than the threshold value, we flag that flow as an anomaly. In this approach, the entropy value is calculated solely by the flow count and its total during the interval. The length of each interval is 1 second for the prototype. However, this value can be adjusted by the users.

# 5 EVALUATION

We evaluate our framework from two perspectives: performance and detection accuracy. For the performance evaluation, we compare our prototype with the user space implementation depicted in Figure 1. To show the efficiency of the fully in-kernel implementation, we measure the performance with different number of CPU cores and the performance during distributed attacks. Furthermore, we compare the detection accuracy with floating-point and static fixed-point implementations to demonstrate the effectiveness of dynamic fixed-point.

We run the measurements on two Linux machines, directly connected by a 10G Ethernet cable. The two machines share the same specifications: Intel i7 11700K @2.5GHz with eight cores (Hyperthreading disabled), X520-AT2 10G NIC, and eight gigabytes of RAM. They run Ubuntu 22.04 with Linux kernel version 6.5.0-21-generic.

## 5.1 Performance scaling: CPU cores

We measure the performance of our frameworks, i.e., fully in-kernel and user space implementations, under limited computing power. We have setup an RFC 2544-like environment for the measurement. Pktgen, a DPDK based packet generator, sends out a total of 1 billion packets at a rate of 12Mpps, or 8.1Gbps [1, 28]. Both implementations process and forward the packets from a different port back to Pktgen. We used the shortest packet size of 64 bytes in this experiment, and the average of five measurements are plotted on the figures.

We show how the throughput changes with the number of CPU cores in Figure 2. The difference between the two implementations are most significant at four CPU cores, about 18.3%. The difference in performance results from reduced number of context switches and memory copies of the fully in-kernel implementation. For eBPF

<figure><img src="image_5.png" /><figcaption>Figure 2: Throughput of varying number of cores.</figcaption></figure>

<figure><img src="image_6.png" /><figcaption>Figure 3: Throughput of varying number of source IP addresses.</figcaption></figure>

+ user space implementation, additional context switches occur between packet processing happening in the kernel space, and the packet analysis happening in the user space. Moreover, additional memory copies are induced per log entry, or source IP address, when reading and updating the log data stored in BPF Maps. Considering the results, these additional overhead is significant enough to affect the throughput, suggesting that there are performance benefits to offloading workloads into eBPF programs.

## 5.2 Performance scaling: Flows

The performance scaling with the number of source IP addresses are shown in Figure 3. This experiment was targeted to determine the capability of the framework to handle large attacks. We increased the number of source IP addresses that Pktgen can use and recorded the results. The experiment was performed with eight CPU cores, with rest of the setup being the same with the experiment in the
<table><caption>Table 2: Characteristics of the dataset.</caption><thead><tr><td>Parameter</td><td>Value</td></tr></thead><tbody><tr><td>Primary protocol</td><td>MQTT</td></tr><tr><td>Normal traffic (pps)</td><td>≈1,000</td></tr><tr><td>Average traffic (pps)</td><td>20,606</td></tr><tr><td>Peak traffic rate (pps)</td><td>245,416</td></tr><tr><td>Total number of packets</td><td>36M</td></tr><tr><td>Legitimate devices</td><td>338</td></tr><tr><td>Compromised devices</td><td>112</td></tr><tr><td>Total number of devices</td><td>450</td></tr></tbody></table>

previous section (subsection 5.1). At 100k IP addresses, the in-kernel implementation has only lost about 7% of its performance compared to its peak at 1k. Meanwhile, the user space implementation had its peak at 100 IP addresses, and lost about 10% and 38% at 10k and 100k IP addresses respectively. The difference in performance curates from the additional memory copies required in the user space + eBPF implementation. These additional copies starts to impact performance after 1k objects, and that impact grows to the point which cannot be ignored after 10k objects. This result suggests that the workloads that frequently incorporate with BPF Maps should be performed by eBPF programs, and not the user space program.

## 5.3 Detection accuracy

We compare the accuracy of floating-point and dynamic fixed-point implementations and investigate whether the use of dynamic fixed-point values would affect the detection accuracy. For our experiment, we created a pcap file from a simulated IoT based DDoS attack. The characteristics of the dataset are described in Table 2.

Dataset was created using GothX [25], a system expanded from Gotham testbed [14]. It leverages GNS3 to simulate a network, using docker containers and virtual machines. It allows generating customized and labeled datasets with legitimate and malicious IoT network traffic. Legitimate traffic includes, among others, some nodes publishing MQTT (Message Queuing Telemetry Transport) messages to the MQTT broker. Malicious traffic are the DDoS attacks from multiple IoT nodes targeting the broker.

In Figure 4, we show how our prototype framework adjust the bit allocation with the number of packets. With the initiation of an attack at around 1300 seconds, the bit allocation is immediately adjusted to the packet count to avoid overflow. It also detects the occasional nosedive in packet count and allocates fewer bits for the integer part. In our implementation, the minimum number of integer bits is seven, thus seven bits is always allocated even when it is excessive.

We show the effect of adjusting the bit allocation in Figure 5. With ROC curves, the closer the curve to the top left, the better the detection accuracy of the implementation. We can see that the detection accuracy of dynamic fixed-point matches to that of floating-point. This indicates that while dynamic fixed-point is still inferior to floating-point in terms of precision, the difference is not significant enough to have a major effect on the detection accuracy in entropy-based approach. This reinforces our idea that dynamic fixed-point is effective in entropy-based anomaly detection.

<figure><img src="image_7.png" /><figcaption>Figure 4: Packet count and bit allocation.</figcaption></figure>

<figure><img src="image_8.png" /><figcaption>Figure 5: Receiver operating characteristic (ROC) curve.</figcaption></figure>

In contrast with dynamic fixed-point, static fixed-point implementations have much lower detection accuracy. This was caused from overflow or under-use of bits. The peak send rate reached 245,416 in this dataset, which requires a minimum of 18 bits to represent. Considering this, it is interesting that the Q16.16 was able to achieve better results than Q24.8. Storing a number over 245k has caused Q16.16 implementation to overflow, but also caused under-use of few integer bits in Q24.8 implementation. This implies that fractional bits are more critical to detection accuracy in entropy-based approach, as overflow in Q16.16 implementation had a smaller impact than under-use of bits in Q24.8 implementation.
# 6 RELATED WORKS

There are works that attempt to use complex algorithms such as machine learning models and neural networks inside eBPF programs.

**Machine learning based approach.** There are works that implemented machine learning models inside eBPF programs. Bachel et al. introduced a flow based intrusion detection system (IDS) using decision trees inside an eBPF program [9]. They trained the model in user space, and re-implemented it inside the eBPF program. Anand et al. goes beyond this work by implementing decision trees, random forest, support vector machine (SVM), and twin SVM to develop an IDS using eBPF [8]. These works report 18% to 185% performance improvement compared to user space implementations. Although these improvements, the baseline performance of these models are sub-par, around 100k to 150k packets per second. Outside of networking, Wang et al. presents 02C, an eBPF-based system to enforce OS kernel compartmentalization [30]. This system uses decision trees to check the data integrity of the system. The promising part of this work is that 02C did not have significant impact on performance, in part from huge performance impact on decision tree models applied for IDS use cases.

**Neural networks.** Potential of neural networks in eBPF programs has also been explored. Hara et al. has experimented on the practicality of packet classification inside the kernel, incorporating neural networks [17]. The neural network consists three layers with a total of 44 nodes, with 32-bit floats quantized to 8-bit integers in order to fit inside eBPF programs. The model inside the kernel demonstrated 84% reduction in inference time, compared to user space implementation. While this reduction is impressive, throughput has only been tested against a flow of 800,000 pps. Performance analysis against a larger flow would be interesting, as that determines whether neural networks are feasible in playing a role in high speed networking. Outside of networking, Chen et al. proposed the benefits of using multi-layer perceptrons as a replacement of the Linux scheduler [12]. The author claims that the 99% of the decisions made by the model was correct, while only incurring 1.9 µs of latency. Many of the studies of implementing machine learning models inside eBPF was in the context of networking, but we expect that more works expand to incorporate machine learning functions into the Linux kernel.

While these works use fixed-point values in their implementations, use of dynamic fixed-point is not discussed. We shed light on dynamic fixed-point and show the effectiveness in improved precision. In combination with dynamic fixed-point, we also incorporate statistical approach to in-kernel anomaly detection framework, which achieves decent detection accuracy with minimal overhead.

# 7 DISCUSSION

Now, the question for discussion is: how feasible is implementation of advanced algorithms inside the Linux kernel? We demonstrated, through the implementation of the prototype, that fixed-point values can emulate floating-point arithmetic inside eBPF programs, opening new ground for advanced algorithms inside eBPF. Dynamic fixed-point in particular, has better calculation accuracy over static fixed-point, to the point which it matches the detection accuracy of floating-point implementations. Furthermore, by containing

system components fully inside the kernel, there are performance gains of up to 18%. From these results, we consider that fully in-kernel entropy-based anomaly detection is feasible and even has the potential to improve performance while maintaining detection accuracy.

**Software emulation of floating-point values.** Floating-point values and dynamic fixed-point values have some similarities, but the major difference is in the approaches to the conversion of the values. Floating-point values and dynamic fixed-point values share the similar characteristic that their precision is dynamic. The key difference exist in the approaches to conversion in each representation. In fixed-point values, real numbers are converted into integers through the multiplication with a fixed number. Inside the CPU, this multiplication is handled as bit shifting, which contributes to the fast processing. However, due to this bit shifting approach, the range of values are strictly limited to the possible maximum and minimum values of that data length. Floating-point values convert the number in a way similar to scientific notation, where the number is expressed with a sign, exponent, and the significand (mantissa). The use of exponents allows for much wider range of values in floating-point values. For example, the maximum and minimum number for Q23.8 fixed-point value, a bit allocation for minimum acceptable precision, is 8388608 and 0.00390625 respectively. Integers larger than that causes overflow and decimal point values smaller than that would be rounded to zero, losing accuracy. On the other hand, floating-point values can represent a significantly wider range from 3.40282347E+38 to 1.17549435E-38 for floating-point values. It is also worth noting that dynamic fixed-point values use additional eight bits to store the bit allocation, slightly increasing the memory consumption of the system. However, we do not consider it to be significant, unless the dynamic fixed-point values are used in very memory restrained system or used in systems that incorporates thousands of dynamic fixed-point values. In our case study with anomaly detection framework, the use of dynamic fixed-point values only adds a couple dozen bytes of memory consumption at most.

Although all the benefits, we do not consider software emulation of floating-point values inside eBPF programs as good practice, as floating-point is more complex than fixed-point values. Additional complexity hinders performance, which is counteractive to our motivation to gain performance with fully in-kernel processing. Furthermore, additional compute complexity leads to additional instruction count. Recall that the complexity of eBPF programs are soft-limited to one million, and hard-limited to 32 million using tail calls. Implementing eBPF programs with software emulated floating-point would have less freedom for the rest of the program, considering the instruction count. Therefore, we conclude that the use of dynamic fixed-point is better as it balances performance, instruction count, and precision, when compared with software emulation of floating-point values and static fixed-point.

**Workloads for in-kernel processing.** We recommend memory-intensive workloads to be performed by eBPF programs. In typical eBPF system implementations, it is common to have user space programs handling some workloads of the system. However, we suggest that BPF Map-intensive workloads be handled by the eBPF programs for additional performance. As we demonstrated in Figure 3, user space + eBPF implementation under-performed
by 55% compared to fully in-kernel implementation when it had to access the BPF Map for intensive number of times. The user space + eBPF implementation must perform additional memory copies when it reads and updates the values stored in BPF Maps, thus curating additional overhead. It is best to leave the BPF Map reading/updating work to the eBPF program.

We do not consider incorporating machine learning models into eBPF programs is practical, especially when there is need for fast processing. Needless to say, machine learning models have tendencies to be computation-intensive, even in very small models. Previous works have incorporated small models, such as decision tree with 1000 nodes or neural networks with three layers, into eBPF programs for use in networking context [8, 9, 17]. However, the overall performance of these systems are sub-par, ranging from 100k pps to 800k pps. In contrast, our prototype with statistics-based approach performed up to 11Mpps. It is also worth to mention that models in previous works use supervised learning, and models with unsupervised learning would have even lower performance due to additional complexity. These works suggest performance of machine learning models in eBPF programs do not scale well with number packets. Significant degradation in throughput undermines the motivation for fully in-kernel processing. Moreover, complexity of models becomes a concern when we consider the instruction count limitation. The eBPF system incorporating neural network for packet classification [17] consists of 56,695 instructions, which is far more than that of our anomaly detection framework (762 instructions). Considering that this model only consists of 3 layers and 44 nodes, the one million instruction count limitation becomes a concern with larger models. Considering the processing speed and the instruction count limitation, we do not recommend the use of machine learning models inside eBPF programs.

**Kernel bypass technologies as an alternative to in-kernel processing.** Technologies such as DPDK and AF_XDP are examples of such bypass technologies. When using kernel bypass technologies, it is effectively skipping the slower workloads such as the allocation of sk_buff and processing of packet by the Linux protocol stack, in favor of packet processing in the user space. The advantages of these technologies are that they enable packet processing in user space, which are free of kernel and eBPF-related restrictions and can still achieve performance levels similar to packet processing inside the XDP program, thanks to zero memory copy functionalities built into them. While kernel bypass technologies are promising technology that achieves high performance whilst being free of restrictions inside the kernel, it lacks the capabilities to cooperate with the Linux kernel or the software that relies on them, such as kubernetes. Access to feature-rich kernel software is where eBPF has advantages over kernel bypass technologies, which is beneficial in the real world with maintenance, additional security, and observability. Using kernel bypass would part with these advantages. Moreover, Parola et al. reports that if we wanted to cooperate AF_XDP with local running applications such as containers, the packet data needs to be returned to the kernel protocol stack for the kernel to pass packet data to the application, hindering performance up to 69% [24]. This is too huge of an impact to overlook. It is also worth to mention that use of busy poll is a requirement in DPDK, and optional but preferred to use, to achieve best performance of AF_XDP. This is not preferable in terms of energy efficiency and

additional latency added to other processes running. We believe that kernel bypass technologies such as DPDK and AF_XDP are promising, there are still advantages of performing advanced packet processing inside the kernel space.

## 8 CONCLUSION

eBPF and XDP are promising technologies that makes fast packet processing possible deep inside the Linux kernel. However, eBPF is imposed of several restrictions to secure the Linux kernel. This includes inaccessibility to floating-point values, which is highly crucial for running advanced algorithms such as statistics based anomaly detection within the kernel space. In this paper, we proposed that dynamic fixed-point value is an effective alternative to floating-point values. To support our proposal, we built a prototype of an anomaly detection framework which uses dynamic fixed-point values to perform anomaly detection completely in kernel space. We achieved 18% performance improvement and similar detection accuracy over the same solution using floating-points in user space. We also found that memory-intensive workloads of over 1k read/write should be performed in eBPF programs, as it removes significant amount of overhead. Lastly, the source code of our system is available at https://github.com/fukuda-lab/FIDe.

## ACKNOWLEDGMENTS

M.P. is supported by the NII internship program. This work has been funded by JST CREST Grant Number JPMJCR21M3 and JSPS KAKENHI Grant Number JP23H00476. We would like to express our sincere gratitude to Luke Korry for his invaluable comments on our work.

## REFERENCES

[1] [n. d.]. DPDK Homepage [Online]. https://www.dpdk.org. (Accessed on 4/9/2024).

[2] [n. d.]. Git commit to mainline Linux kernel (1M instruction limit) [Online]. https://github.com/torvalds/linux/commit/04c0d2b968ac45d6ef020316808ef6c82325a82. (Accessed on 4/21/2024).

[3] [n. d.]. Git commit to mainline Linux kernel (addition of tail call) [Online]. https://github.com/torvalds/linux/commit/04fd61ab36ec065e194ab5e74ae34a5240d992bb. (Accessed on 4/21/2024).

[4] [n. d.]. Libbpf[Online]. https://github.com/libbpf/libbpf. (Accessed on 5/9/2024).

[5] [n. d.]. [PATCH v3 bpf-next 0/9] bpf: bounded loops and other features [Online]. https://lwn.net/ml/netdev/20190615191225.2409862-1-ast@kernel.org/. (Accessed on 4/14/2024).

[6] 2003. TMS320C64X DSP Library Programmer's reference - Texas. https://www.ti.com/lit/ug/spru565b/spru565b.pdf (Accessed on 5/3/2024).

[7] Muhammad Aamir and Syed Mustafa Ali Zaidi. 2021. Clustering based semi-supervised machine learning for DDoS attack classification. *Journal of King Saud University - Computer and Information Sciences* 33, 4 (2021), 436–446. https://www.sciencedirect.com/science/article/pii/S131915781831067X

[8] Nenalikanti Anand, Saifulla M a, and Pavan Aakula. 2023. High-performance Intrusion Detection Systemusing eBPF with Machine Learning algorithms. https://doi.org/10.21203/rs.3.rs-3140072/v1

[9] Maximilian Bachl, Joachim Fabini, and Tanja Zseby. 2021. A flow-based IDS using Machine Learning in eBPF. arXiv preprint arXiv:2102.09980 (2021).

[10] Gilberto Bertin. 2017. XDP in practice: integrating XDP into our DDoS mitigation pipeline. In *Technical Conference on Linux Networking, Netdev*, Vol. 2. The NetDev Society, 1–5.

[11] Matteo Bertrone, Sebastiano Miano, Fulvio Risso, and Massimo Tumolo. 2018. Accelerating linux security with ebpf iptables. In *Proceedings of the ACM SIGCOMM 2018 Conference on Posters and Demos*. 108–110.

[12] Jingde Chen, Subho S. Banerjee, Zbigniew T. Kalbarczyk, and Ravishankar K. Iyer. 2020. Machine learning for load balancing in the Linux kernel. In *Proceedings of the 11th ACM SIGOPS Asia-Pacific Workshop on Systems* (Tsukuba, Japan) (APSys '20). Association for Computing Machinery, New York, NY, USA, 67–74. https://doi.org/10.1145/3409963.3410492
[13] Jisa David and Ciza Thomas. 2015. DDoS Attack Detection Using Fast Entropy Approach on Flow-Based Network Traffic. Procedia Computer Science 50 (2015), 30-36.

[14] X. Saez de Camara, J. Flores, C. Arellano, A. Urbieta, and U. Zurutuza. 2024. Gotham Testbed: A Reproducible IoT Testbed for Security Experiments and Dataset Generation. IEEE Transactions on Dependable and Secure Computing 21, 01 (jan 2024).

[15] Cong Fan, Nitheesh Murugan Kaliyamurthy, Shi Chen, He Jiang, Yiwen Zhou, and Carlene Campbell. 2022. Detection of DDoS Attacks in Software Defined Networking Using Entropy. Applied Sciences 12, 1 (2022). https://www.mdpi.com/2076-3417/12/1/370

[16] Brenden Gregg. 2019. BPF Performance Tools: Linux System and Application Observability. Pearson Education, Hoboken.

[17] Takanori Hara and Masahiro Sasabe. 2023. On Practicality of Kernel Packet Processing Empowered by Lightweight Neural Network and Decision Tree. In 2023 14th International Conference on Network of the Future (NoF). 89-97. https://doi.org/10.1109/NoF58724.2023.10302811

[18] Toke Høiland-Jørgensen, Jesper Dangaard Brouer, Daniel Borkmann, John Fastabend, Tom Herbert, David Ahern, and David Miller. 2018. The eXpress data path: fast programmable packet processing in the operating system kernel. In Proceedings of the 14th International Conference on Emerging Networking Experiments and Technologies (Heraklion, Greece) (CoNEXT '18). Association for Computing Machinery, New York, NY, USA, 54-66. https://doi.org/10.1145/3281411.3281443

[19] Tamás Lévai, Balázs Edvárd Kreith, and Gábor Rétvári. 2023. Supercharge WebRTC: Accelerate TURN Services with eBPF/XDP. In Proceedings of the 1st Workshop on eBPF and Kernel Extensions. 70-76.

[20] Sebastiano Miano, Matteo Bertrone, Fulvio Risso, Mauricio Vásquez Bernal, Yun-song Lu, and Jianwen Pi. 2019. Securing Linux with a faster and scalable iptables. ACM SIGCOMM Computer Communication Review 49, 3 (2019), 2-17.

[21] Ali Mustapha, Rida Khatoun, Sherali Zeadally, Fadlallah Chbib, Ahmad Fad-lallah, Walid Fahs, and Ali El Attar. 2023. Detecting DDoS attacks using ad-versarial neural network. Computers & Security 127 (2023), 103117. https://www.sciencedirect.com/science/article/pii/S0167404823000275

[22] Giseop No and Ilkyeon Ra. 2009. An efficient and reliable DDoS attack detection using a fast entropy computation method. In 2009 9th International Symposium on Communications and Information Technology. 1223-1228. https://doi.org/10.1109/ISCIT.2009.5341118

[23] Sagar Pande, Aditya Khamparia, Deepak Gupta, and Dang N. H. Thanh. 2021. DDoS Detection Using Machine Learning Technique. Springer Singapore, Singapore, 59-68. https://doi.org/10.1007/978-981-15-8469-5_5

[24] Federico Parola, Roberto Procopio, Roberto Querio, and Fulvio Risso. 2023. Comparing User Space and In-Kernel Packet Processing for Edge Data Centers. SIGCOMM Comput. Commun. Rev. 53, 1 (apr 2023), 14-29. https://doi.org/10.1145/3594255.3594257

[25] Manuel Poisson, Rodrigo Carnier, and Kensuke Fukuda. 2024. GothX: a generator of customizable, legitimate and malicious IoT network traffic. Proc. 17th Workshop on Cyber Security Experimentation and Test (CSET) (2024), 9.

[26] Christian Scheich, Marius Corici, Hauke Buhr, and Thomas Magedanz. 2023. eXpress Data Path Extensions for High-Capacity 5G User Plane Functions. In Proceedings of the 1st Workshop on eBPF and Kernel Extensions. 86-88.

[27] Simon Sundberg, Anna Brunstrom, Simone Ferlin-Reiter, Toke Høiland-Jørgensen, and Jesper Dangaard Brouer. 2023. Efficient continuous latency monitoring with eBPF. In International Conference on Passive and Active Network Measurement. Springer, 191-208.

[28] Daniel Turull, Peter Sjödin, and Robert Olsson. 2016. Pktgen: Measuring performance on high speed networks. Computer Communications 82 (2016), 39-48.

[29] Marcos A. M. Vieira, Matheus S. Castanho, Racyus D. G. Pacifico, Elerson R. S. Santos, Eduardo P. M. Câmara Júnior, and Luiz F. M. Vieira. 2020. Fast Packet Processing with eBPF and XDP: Concepts, Code, Challenges, and Applications. ACM Comput. Surv. 53, 1, Article 16 (feb 2020), 36 pages. https://doi.org/10.1145/3371038

[30] Zicheng Wang, Tiejin Chen, Qinrun Dai, Yueqi Chen, Hua Wei, and Qingkai Zeng. 2024. When eBPF Meets Machine Learning: On-the-fly OS Kernel compartmentalization. arXiv:2401.05641 [cs.OS]

[31] Xiaoyong Yuan, Chuanhuang Li, and Xiaolin Li. 2017. DeepDefense: Identifying DDoS Attack via Deep Learning. In 2017 IEEE International Conference on Smart Computing (SMARTCOMP). 1-8. https://doi.org/10.1109/SMARTCOMP.2017.7946998

[32] Yuhong Zhong, Haoyu Li, Yu Jian Wu, Ioannis Zarkadas, Jeffrey Tao, Evan Mesterhazy, Michael Makris, Junfeng Yang, Amy Tai, Ryan Stutsman, and Asaf Cidon. 2022. XRP: In-Kernel Storage Functions with eBPF. In 16th USENIX Symposium on Operating Systems Design and Implementation (OSDI 22). USENIX Association, Carlsbad, CA, 375-393. https://www.usenix.org/conference/osdi22/presentation/zhong