聊聊最近很火的eBPF - 知乎

如果非要说当前计算机领域最有前途的两个基础软件技术，那非eBPF和wasm莫属了。

什么是eBPF？

Linux内核一直是实现监视/可观察性，网络和安全性的理想场所。不幸的是，这通常是不切实际的，因为它需要更改内核源代码或加载内核模块，并导致彼此堆叠的抽象层。 eBPF是一项革命性的技术，可以在Linux内核中运行沙盒程序，而无需更改内核源代码或加载内核模块。通过使Linux内核可编程，基础架构软件可以利用现有的层，从而使它们更加智能和功能丰富，而无需继续为系统增加额外的复杂性层。

eBPF导致了网络，安全性，应用程序配置/跟踪和性能故障排除等领域的新一代工具的开发，这些工具不再依赖现有的内核功能，而是在不影响执行效率或安全性的情况下主动重新编程运行时行为。

如果直接解释eBPF，有点不明所以。那我们就看看有哪些基于eBPF的工程，这些工程或许你已经知道，或是已经经常使用，也许你会明白eBPF距离我们并不遥远。

基于eBPF的项目

1： bcc

BCC是用于创建基于eBPF的高效内核跟踪和操作程序的工具包，其中包括一些有用的命令行工具和示例。 BCC简化了用C进行内核检测的eBPF程序的编写，包括LLVM的包装器以及Python和Lua的前端。它还提供了用于直接集成到应用程序中的高级库。

2： bpftrace

bpftrace是Linux eBPF的高级跟踪语言。它的语言受awk和C以及DTrace和SystemTap等以前的跟踪程序的启发。 bpftrace使用LLVM作为后端将脚本编译为eBPF字节码，并利用BCC作为与Linux eBPF子系统以及现有Linux跟踪功能和连接点进行交互的库。

3： Cilium

Cilium是一个开源项目，提供基于eBPF的联网，安全性和可观察性。它是从头开始专门设计的，旨在将eBPF的优势带入Kubernetes的世界，并满足容器工作负载的新可伸缩性，安全性和可见性要求。

4： Falco

Falco是一种行为活动监视器，旨在检测应用程序中的异常活动。 Falco在eBPF的帮助下审核Linux内核层的系统。它使用其他输入流（例如容器运行时度量标准和Kubernetes度量标准）丰富了收集的数据，并允许连续监视和检测容器，应用程序，主机和网络活动。

5： Katran

Katran是一个C ++库和eBPF程序，用于构建高性能的第4层负载平衡转发平面。 Katran利用Linux内核中的XDP基础结构来提供用于快速数据包处理的内核功能。它的性能与NIC接收队列的数量成线性比例，并且使用RSS友好的封装转发到L7负载平衡器。

6： Sysdig

Sysdig是提供深层系统可见性的简单工具，并具有对容器的原生支持。

其他基于eBPF技术的项目还有很多，比如 kubectl-trace， ply等，这里不再赘述。

如何编写一个eBPF程序？

在很多情况下，不是直接使用eBPF，而是通过Cilium，bcc或bpftrace等项目间接使用eBPF，这些项目在eBPF之上提供了抽象，并且不需要直接编写程序，而是提供了指定基于意图的定义的功能，然后使用eBPF实施。

如果不存在更高级别的抽象，则需要直接编写程序。 Linux内核希望eBPF程序以字节码的形式加载。虽然当然可以直接编写字节码，但更常见的开发实践是利用LLVM之类的编译器套件将伪C代码编译为eBPF字节码。

在编写eBPF程序之前，需要简单了解几个概念。

1）map(映射) ：BPF最令人着迷的方面之一是，内核上运行的代码和加载了该代码的程序可以在运行时使用消息传递相互通信。

BPF映射是驻留在内核中的键/值存储。任何BPF程序都可以访问它们。在用户态中运行的程序也可以使用文件描述符访问这些映射。只要事先正确指定数据大小，就可以在映射中存储任何类型的数据。内核将键和值视为二进制 blobs，它并不关心您在映射中保留的内容。

BPF验证程序包括多种保护措施，以确保您创建和访问映射的方式是安全的。当我们解释如何访问这些映射中的数据时，我们也将解释这些保护措施。

当然BPF映射类型有很多，比如哈希表映射，数组映射，Cgroup 数组映射等，分别满足不同的场景。

2）验证器

BPF验证程序也是在您的系统上运行的程序，因此，对其进行严格审查是确保其正确执行工作的目标。

验证程序执行的第一项检查是对VM即将加载的代码的静态分析。第一次检查的目的是确保程序有预期的结果。为此，验证程序将使用代码创建有向循环图（DAG）。验证程序分析的每个指令将成为图中的一个节点，并且每个节点都链接到下一条指令。验证程序生成此图后，它将执行深度优先搜索（DFS），以确保程序完成并且代码不包含危险路径。这意味着它将遍历图的每个分支，一直到分支的底部，以确保没有递归循环。

这些是验证器在第一次检查期间可能拒绝您的代码的情形，要求有以下几个方面：

• 该程序不包含控制循环。为确保程序不会陷入无限循环，验证程序会拒绝任何类型的控制循环。已经提出了在BPF程序中允许循环的建议，但是截至撰写本文时，没有一个被采用。
• 该程序不会尝试执行超过内核允许的最大指令数的指令。此时，可执行的最大指令数为4,096。此限制是为了防止BPF永远运行。在第3章，我们讨论如何嵌套不同的BPF程序，以安全的方式解决此限制。
• 该程序不包含任何无法访问的指令，例如从未执行过的条件或功能。这样可以防止在VM中加载无效代码，这也会延迟BPF程序的终止。
• 该程序不会尝试越界。

验证者执行的第二项检查是BPF程序的空运行。这意味着验证者将尝试分析程序将要执行的每条指令，以确保它不会执行任何无效的指令。此执行还将检查所有内存指针是否均已正确访问和取消引用。最后，空运行向验证程序通知程序中的控制流，以确保无论程序采用哪个控制路径，它都会到达BPF_EXIT指令。为此，验证程序会跟踪堆栈中所有访问过的分支路径，并在采用新路径之前对其进行评估，以确保它不会多次访问特定路径。经过这两项检查后，验证者认为程序可以安全执行。

3) hook ： 由于eBPF是事件驱动的，所以ebpf是作用于具体的hook的。根据不同的作用，常用的有XDP，trace，套接字等。

4）帮助函数：eBPF程序无法调用任意内核功能。允许这样做会将eBPF程序绑定到特定的内核版本，并使程序的兼容性复杂化。取而代之的是，eBPF程序可以调用帮助函数，该函数是内核提供的众所周知且稳定的API。

总结

安全，网络，负载均衡，故障分析，追踪等领域都是eBPF的主战场。

对于云原生领域，Cilium 已经使用eBPF 实现了无kube-proxy的容器网络。利用eBPF解决iptables带来的性能问题。

整个eBPF生态发展比较好，社区已经提供了诸多工具方便大家编写自己的eBPF程序。