Deep Application Visibility, Powered by eBPF

Gain Deep Application with the Power of eBPF

Between the open source software supply chain and today’s distributed architectures, software development has become so complex that it’s difficult to get true insight into what is going on with your applications. SCA, ASPM, and even CSPM tools are noisy – they point to problems but provide no context, and they generate reams of false positives.

Our goal in developing Kodem is to provide insight, context, and prioritization that simplifies application security for modern, cloud-focused teams. We do this by analyzing how applications interact during runtime, so we can focus on functions that are actually being used in runtime. When prospects see the clear context and focus they can achieve with our platform, they naturally ask how it’s done.

We do this through a technology called Extended Berkeley Packet Filter, or eBPF. 

What is eBPF and How Does it Work?

Extended Berkeley Packet Filter is a Linux kernel extension that’s been part of the Linux kernel since version 3.18. It has shipped with every major Linux distribution for years, including Ubuntu, Debian, RHEL, Alpine, CentOS, Fedora, and Mint. It’s a mature, proven technology; various types of eBPF applications are used in production every day at companies like Apple, Netflix, Meta, LinkedIn, Datadog, and Google. 

The technology is purpose-built to run sandboxed programs safely inside the Linux kernel. Kodem uses a sensor written as an eBPF program. An eBPF program can monitor events like system calls and networking, letting Kodem see and subscribe to events at the kernel level without impacting the overall stability or security of the system. As your application executes, loads other code, moves data, etc., Kodem sees it all.  

eBPF Sensors Watch Events at the Kernel Level

If you want to write code that watches what’s going on at the kernel level, the best way to do that is with eBPF. An eBPF program runs in a sandbox at the kernel level, so we have access to system events while the sandbox prevents our code from doing anything that might have a negative impact on the system. An eBPF program can be loaded and executed at runtime without rebooting the system, allowing you to extend the behavior of the system at runtime. Finally, eBPF is very lightweight; Kodem’s solution uses a negligible percentage of an application’s resources, typically taking no more than 0.1% of CPU.

There are other ways to get kernel visibility other than eBPF. For example, you could make changes to the kernel itself to let you see everything that’s going on in the system. That would be extremely powerful, but it could take months or more for your changes to be accepted and pulled into the kernel. And years beyond that before most Linux vendors have shipped the updated kernel you need. Obviously that’s not practical. 

Another approach would be to write a kernel module that runs inside the existing kernel. You won’t have to wait for the community to adopt it, but you won’t have any guardrails to make sure your code doesn’t cause problems. No matter how careful you are in writing your kernel module, there’s no limit to the damage it can do if something goes wrong. And there are no guarantees that new versions of the kernel won’t break your code. 

For access to system events at the kernel level, eBPF really shines.  

The Components of eBPF

eBPF has several parts that work together to make it possible for the Kodem platform to deliver Runtime Intelligence. 

When an eBPF program is loaded into the kernel, the eBPF Verifier ensures that the program is safe to run; an eBPF program cannot crash or create a fault in the kernel. The verifier  makes sure the program doesn’t use uninitialized variables, is small enough to be loaded, can’t get into an infinite loop, and isn’t too complex. (To check complexity, the verifier goes through every possible execution path in the code; if that doesn’t complete quickly, the program is rejected.) If the program fails any of these checks, it isn’t loaded.  

If code is approved by the verifier, the eBPF JIT compiler is a very powerful optimization layer that is inspired by other JIT runtimes built for different application frameworks. It translates the generic bytecode of the program into the machine specific instruction set to optimize execution speed of the program. 

The eBPF Sandbox was designed from the ground up with security in mind, so there are limits to what an eBPF program can do. For example, an eBPF program can’t access arbitrary system calls, and it can’t do anything that changes the kernel state. On the other hand, eBPF programs can do things like modify network packets or access socket data. 

When an eBPF program is initialized, eBPF Maps are created, Maps are data structures that store and manage state information. An eBPF Map is the only way to pass information from an eBPF program, and it can be accessed by a set of predefined applications at the time of the request. 

These eBPF programs are event-driven, so eBPF uses Hooks to trigger them. When a certain event happens, the eBPF program attached to that event is run. Predefined hooks exist for system calls, function entry / exit, network events, and several others. In addition, there is a mechanism to create hooks for other events. 

By design, eBPF is also extremely lightweight. The Kodem sensor uses less than 0.1% of an application’s resources. Other uses of eBPF are similarly efficient, such as observability and network monitoring. 

Five benefits of using an eBPF-based sensor

The eBPF sensor has many advantages. By invoking kernel functions, it’s easier to write and maintain, enabling instant monitoring and security for your application.

‍

Here are a few of the highlights: 

1. Speed and performance. The eBPF functionality can move packet processing from the kernel-space into the user-space. To speed things up even further, eBPF uses a just-in-time (JIT) compiler to convert an eBPF program into bytecode. When that compilation is done, eBPF reuses the bytecode instead of recompiling it.
2. Unobtrusiveness. Because eBPF is running in the kernel-space, an eBPF program can monitor your application right away. You don’t have to rewrite, redeploy, or even restart your code. 
3. Security. Because eBPF runs in the kernel-space, it was designed from the ground up with security in mind. That’s why eBPF programs run in a sandbox. They can’t call into arbitrary kernel functions, and they can’t do anything that changes the state of the kernel. 
4. Convenience. An eBPF program works by invoking kernel functions. That’s much easier to write and maintain than a new kernel module. A kernel module could be broken by each new version of the kernel, and it won’t have any security boundaries to keep it from causing trouble. 
5. Negligible performance impact. The eBPF technology is as lightweight as it is powerful. The overhead of an eBPF program that does security analysis is typically less than 0.1%. eBPF programs that do performance monitoring, load balancing, and infrastructure observability are similarly lightweight. 

The dynamic nature of eBPF means you don’t have to modify, recompile, or redeploy your code to use the Kodem platform.  The sandbox-based design of eBPF allows the Kodem sensor to see how your application interacts with the operating system. This gives you deep application insight and lets application security teams focus on the vulnerabilities that can actually be exploited instead of wasting time chasing false positives. 

Discover how Kodem harnesses the potential of eBPF
Watch the Kodem Platform Overview Video >>

‍