# eBPF: rethinking the linux kernel

* Programmability essentials 
  * Safety --> sandboxing 
  * Continuous Delivery --> deploy anytime with seamless upgrades 
  * Performance --> native execution (JIT compiler) 
* Kernel architecture 
  * Kernel abstracts using driver: enable the H/W, but don't want to expose 
    * Block device, network device 
  * System calls: application invokes to communicate with kernels 
  * Middle logic: business logic 
    * Virtual file system
    * TCP / IP 
  * Last piece: someone operates the system, through configuration APIs 
    * Interact from the kernel through the APIs 

![](/files/ZsjqW7ZD6RdebowUNWQd)

#### Kernel Development 101 

* Option 1: native support 
  * Change kernel source code
  * Expose configuration API 
  * Wait 5 years for your users to upgrade 
  * Cons: nobody wants to wait 
* Option 2: kernel module 
  * Write kernel module
  * Every kernel release will break it 
  * Cons
    * You likely to ship a different module for each kernel version
    * Might crash your kernel 

#### How about we add JS-like capabilities to the Linux Kernel?

* eBPF

  * Take that syscall, and run a program that takes over on behalf of the system call and then returns 
  * ![](/files/NSsUSmwPv9JUV1YWYqSx)
  * Extract the metadata from the system call, and send that through a bpf map, for tracing purpose and provide context 

* **eBPF runtime**: how does that work? 
  * Runtime: ensure that we fulfill all the programmability essentials that we cover earlier
  * BPF bytecode: the compiled version of the code above  
    * Safety & security: the verifier will reject any unsafe program and provides a sandbox 
      * Major difference compared to the Linux module 
      * Privilege, access / expose control 
      * Similar to JS (software-based sandbox) 
    * Performance: JIT compiler --> ensures native execution performance 
      * Portable 
    * Continuous Delivery 
      * Programs can be exchanged without disrupting workloads 

![](/files/pgOeVk5I0FStLodAEvs2)

* eBPF Hooks 

![Hooks](/files/4sLx4Sbm31g7ewZUnrOF)

* **What can you hook?** 
  * Kernel functions (kprobes)
  * Userspace functions (uprobes) 
    * Functions in your application! Profile application 
  * System calls 
  * Tracepoints 
    * Function names in kernel that will stay stable 
    * Instrument the entire Linux kernel
  * Network devices (tc / xdp)
  * Network routes 
  * TCP congestion algorithms
  * Sockets (data level) 

#### eBPF Maps 

![](/files/SEmlnDDj9QHuz8mHGLmd)

* BPF program: only instructions, no data 
* States are stored in BPF maps, separate from the programs 
  * Keep the maps alive, while replacing the programs
    * E.x. LPM --> routing table 
  * Seamless upgrades 
* Used for 
  * Retrieve and configure 

#### eBPF helpers 

![](/files/eASgvkjtlVIcV9fJ1uqa)

* Linux module can call any kernel functions 
  * Downsides: abuse or misuse --> crash the kernel, and are not stable 
* BPF programs
  * Helpers: used to interact with OS, and they are stable over time 
  * Interactions with OS are done via helpers
  * Portable across kernel versions 

#### eBPF Tail and Function calls 

![](/files/iO5lT8Tbpz5WV8LtCewW)

* Tail calls: chain, and will not return to the old programs 
  * Hook: run multiple logical pieces 
* Tail / function calls 

  * Composable 
  * Reduce the size of the programs 

![](/files/eqiUhHjyoscrVgN4HEVM)

#### Applications 

* Tracing & Profiling with eBPF 
  * BCC: BPF compiler collection 
    * Allow application developers to run a python program, which contains the actual BPF program and the logic in python to read the state / metrics from BPF maps and displays it in some way 
  * bpftrace - Dtrace for Linux 
    * Creating BPF maps, read it, and so on 
  * Cilium: networking, load-balancing, and security for Kubernetes 
    * Network policies, Kubernetes services and so on 
    * Introspect the data 

![](/files/l5kw0eLzSCIIzM2RXcSx)

![](/files/se9LNEJ2oPkuqAEgAPB0)

![](/files/ws8XZChBmcveXhnLUvNk)

![](/files/2iplE4wiIH7GO0OAd9Sk)

![](/files/gKiOF6FAm06MzJIbg8GY)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://sliu583.gitbook.io/blog/specific-work/seminar-and-talk/fall-21-reading-list/ebpf-rethinking-the-linux-kernel.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.