What Is eBPF? The Ultimate Guide
eBPF is one of the most justifiably hyped technologies out there, one that has demonstrated its worth and applicability in cloud native environments. Its ability to improve computing efficiency and enhance the computing ability for numerous tools and platforms, particularly for security, observability and networking, is evident.
eBPF stands for extended Berkeley packet filter. Architecture for an extended Berkeley Packet Filter includes elements like program verification, helper calls, eBPF maps, predefined hooks, function and tail calls.
So what is eBPF beyond a cloud native technology and where does it get its superpowers? The power of eBPF largely lies in its computing efficiency since it is directly tied to the Linux kernel. However, labeling eBPF solely as a Linux kernel-based tool would be misleading, as its impact is spread across the stack, impacting the applications to which it’s applied.
A significant aspect of the beauty of eBPF is that it has been used and applied in various ways through open source projects. In contrast to other technologies like WebAssembly, which promise computing efficiency and the ability to initiate commands across endpoints simultaneously, eBPF has delivered on its potential. WebAssembly’s challenges with standardization have hindered its applicability across different endpoint use cases.
How Is eBPF Different?
To use industry jargon, it is sandboxed to run and offers various capabilities that extend for user processes, covering use cases ranging from observability, security, networking, tracing and acting as a replacement for the sidecar and service mesh.
Without using the overused term “sandboxed,” it can be said that eBPF runs from within the kernel allowing runtimes with it to run in a closed environment. In other words, it removes a potential attack vector since bad actors cannot write or access it as they might if it were running within a container, a pod or somewhere else with shared privileges.
eBPF is being utilized in diverse ways and has formed the foundation of numerous successful commercial projects. For security purposes, it has been a driving force. Overcoming obstacles that once hindered eBPF adoption has paved the way for various tools and platforms that not only surmount these challenges but also enhance efficiency across security, observability, networking and other applications.
This is largely because companies or organizations that wish to leverage eBPF might lack the resources to develop in-house hyperscalers or the expertise to directly harness eBPF’s advantages. This is where BPF tool providers and platform providers come into play. Their expertise fills the gap, encompassing understanding of Linux (technically Unix) to create processes using kernel code needed to run eBPF applications or devices. Furthermore, some Linux kernels do not support eBPF, but tool providers have worked around this limitation.
How to Prepare for eBPF?
But since eBPF code resides in the Linux kernel, security concerns can arise from some:
“Executing custom code in the kernel, by definition, always creates an attack surface for the bad guys to exploit,” Torsten Volk, an analyst for Enterprise Management Associates (EMA), said. “However, the countermeasures are very similar to the ones ensuring security for the rest of the stack: update your kernel, ensure centralized monitoring of all eBPF apps, apply a central set of security policies and create centralized auditing are some of the key pillars of this strategy.”
Gartner offers the following user recommendations:
- For organizations that are still using eBPF Linux distributions with limited or no eBPF support, migrate to more modern platforms
- Seek eBBF Kubernetes container networking infrastructure (CNI) solutions when scale, performance, visibility and security are top of mind.
- Use eBPF Linux variants that provide eBPF support to enable network performance, visibility and eBPF security products.
- Explore whether eBPF can meaningfully address the organization’s performance or visibility challenges by supporting technologically advanced enterprises.
- Invest in eBPF to improve performance and visibility, to avoid falling behind competitors, for networking and network security vendors.
The ability to directly monitor and interact with system calls, threads and processes, combined with direct access to latency and utilization metrics, all in real-time, makes eBPF an excellent platform for security and observability applications, Volk said.
In short, “eBPF is great for rapidly changing microservices apps, as server nodes can be monitored across clouds and the latency of function calls can be traced without manual instrumentation, as long as they run Linux with eBPF support,” Volk said. “Leveraging eBPF capabilities is a no-brainer, as this technology can be adopted gradually and without the need to give up traditional observability, networking, or security tools.”
Is eBPF ‘Based’ on the Linux Kernel?
It has often been written and said that eBPF is “based” on the Linux kernel. This is not entirely correct. As is often the case when the word “based” is used to describe a technology, understanding how eBPF and its relationship with the Linux kernel functions first requires a definition or description of the Linux kernel itself.
The Linux kernel is considered the core code or the heart of the Linux operating system. The kernel determines, for example, which user processes and drivers have limited access to the CPU and memory to execute their functionalities.
But eBPF functions do not change the kernel; instead, it has direct access to the CPU and memory. Remember, the kernel serves as a mediator, in a sense and as such, eBPF does not change the kernel code. However, it bypasses the kernel in a certain way by functioning or working directly and connecting directly with the CPU and memory.
Hence, a significant source of its power is not unlike WebAssembly. Although there’s an inverse relationship with WebAssembly, as it interacts with the CPU at the endpoints to which the code within a WebAssembly module is distributed.
In this manner, eBPF runs, adds to, or even extends the Linux kernel as a feature of the operating system or, more specifically, the kernel itself. Again, since it’s part of the kernel itself, this Linux Foundation project can essentially extend anywhere Linux-compatible user processes and applications run. This extension covers a range from servers in data centers to highly distributed Kubernetes environments for cloud native applications.
Microsoft was one of the creators of the eBPF Foundation in 2021, along with Google, Isovalent, Meta and Netflix and once again, it is a Linux Foundation project. Microsoft is scarcely a primary advocate for Windows, despite its well-documented performance, security and other issues compared to the Linux operating system. This accounts for the existence of eBPF for Windows.
Although eBPF for Windows has yet to achieve widespread adoption like its Linux eBPF counterpart, Microsoft continues to offer demonstrations of its use and multiple hooks.
Microsoft describes eBPF not within the context of the Linux kernel, but as a part of operating systems in general — specifically, the Windows operating system.
What Are the Security Risks of eBPF?
But doesn’t eBPF code pose a security risk since it runs directly in the kernel?
How eBPF is integrated with the Linux Kernel might raise security concerns for some. After all, having malicious code with direct access to the operating system and the CPU is something no one wants except for attackers.
To address this eBPF security concern, the eBPF Verifier checks the code and only grants eBPF write privileges after verifying that the program is licensed under GPL, to help ensure its security and compatibility. Of course, nothing is entirely foolproof, but up until now, major attacks orchestrated through eBPF at the kernel level have not been reported.
What Is the Difference between BPF vs. eBPF?
The first reported instance of then BPF consisted of the Berkeley Packet Filter merging with the Linux kernel compiler in 2010. Its first reported use for non-networking purposes is attributed to Google Principal Software Engineer Will Drewry, who found that configuring BPF for the networking layer served as the proper seccomp — secure computing mode for the Linux kernel. This reported finding in 2012 served as the genesis for security and other hooks that would set the stage for more exciting developments to come.
If you consider BPF by itself, it’s about efficiently handling packets and eBPF extends these capabilities. The first instance of eBFF reportedly came about in 2014 and then, as now, remains a work in progress. Initially focused mainly on networking, it was subsequently expanded to include system calls and other functionalities, occasionally incorporating similar elements. This expansion led to the term “fully extended Berkeley packet filter.”
The difference in nomenclature from BPF vs. eBPF can even be attributed to marketing, said CEO and co-founder Shauli Rozen of ARMO, which offers ARMO Platform, an enterprise-grade Kubernetes security platform powered by Kubescape.
“It was a way to rekindle interest in something powerful that had not yet gained enormous traction,” Rozen said. “ARMO is using a lot of observability data from the BPF to add value to your security measures and assist in prioritization. You are aware of the security efforts you’re implementing to enhance your environment, based on the observability data generated.”
What’s so special about what eBPF brings to networks, especially in cloud native environments?
eBPF has also been shown to allow significant network gains in networking productivity. This is largely due, once again, to the fact that eBPF is in the kernel and thus directly directs traffic to the CPU. Techniques like XDP load balancing are replaced in many instances with these networking capabilities.
There are built-in features for eBPF observability, as well as for eBPF security. This is also implemented through hooks, of course, pre-implemented throughout a network. Thanks to the hooks put in that reside within the kernel.
What Is XDP?
XDP stands for Express Data Path. Of course, this facilitates the transfer of packets and observability across different communication layers, ranging from layer seven for HTTP, DNS, or gRPC, layer four for TCP, the IP layer, layer three, etc. and, of course, Ethernet and WiFi within layer two.
eBPF allows for communication between these different layers. This way, efficiency also pertains to how the kernel uses BPF as an arbitrator to direct the packets where they should go. In terms of sandboxing, there is less risk of dropping packets, etc. These packets, of course, can have their data modified in real-time, directly through eBPF-sandboxed code.
One of the major projects is Cilium, an open source project. Cilium offers networking, observability and eBPF security solutions. As for networking, its usage ranges between Layer Three and Layer Seven networking layers. Cilium also facilitates and implements distributed load balancing for traffic in Kubernetes environments between pods and external services.
This includes integrated ingress/egress, Gateway, bandwidth management, service mesh and deep networking security. Public visibility monitoring in the aspect of service mesh has shown a lot of promise, replacing the sidecar, which seemed to slow down data traffic when using service mesh for the management of Kubernetes clusters and pods.
How Is eBPF Used for Kubernetes?
A number of platforms and eBPF tools have emerged that rely on eBPF to detect threats and enforce security policies. As mentioned above, the effort to apply eBPF for security largely began when BPF started serving as the proper seccomp for the Linux kernel and processes accessing the kernel.
A proper platform that uses eBPF should be able to allow DevOps teams to monitor what should be running in the Kubernetes cluster and offer actionable results when policies are violated or security threats are detected.
In the case of Kubernetes security provider ARMO’s open source Kubescape, the Cloud Native Computing Foundation sandbox project covers the lifecycle of applications and their updates for Kubernetes applications.
This includes IDEs, CI/CD pipelines and clusters for risk analysis, security, compliance, misconfiguration scanning and image scanning. Hardening recommendations such as network policies and security policies are also available as part of open source offerings.
Kubescape is used to integrate with a checklist of the necessary tools your DevOps teams for use with the platform, such as software bill of materials (SBOM), signature scanning and policy controls. It begins running its scans at the very beginning of the development cycle and extends across CI/CD and throughout the deployment and cluster management process.
A recent capability with eBPF that ARMO offers applies to vulnerabilities relevancy and prioritization. Relevancy and prioritization allow ARMO Platform and Kubescape users to deprioritize vulnerabilities that belong to unused software packages and components. By first deprioritizing vulnerabilities that are less critical, users can focus on addressing the ones that pose a greater threat to their running cluster.
“You can’t protect what can’t be seen, which is why observability is critical,” Rozen said. “Indeed, utilizing a significant amount of observability data from eBPF and applying it to assist DevOps teams in prioritizing and taking action only for true security threats and vulnerabilities that require attention is key.”