一文读懂内核可编程技术eBPF.docx

内核，在现代计算架构中扮演着至关重要的角色，它直接管理着系统资源并执行底层操作。出于系统安全性的考虑，对内核的访问权限被严格限制。这种机制有效地防止了潜在的系统破坏，但也带来了一项挑战：由于用户应用程序无法直接访问内核空间，它们难以检测到那些仅在内核级别才能观察到的低级网络和安全事件。

为了应对这一挑战，eBPF技术应运而生。它允许用户在内核空间内运行经过安全验证的代码，而无需修改内核源代码或加载额外的内核模块。这一创新性的技术为内核功能扩展提供了极大的灵活性。

eBPF解决了什么问题？

为了更好地回答这个问题，了解eBPF的起源以及它是如何从最初的BerkeleyPacketFilter（BPF）发展而来会有所帮助。

BPF?于1993年推出，旨在实现对网络流量的有效控制与筛选。在BPF出现之前，数据包过滤工具大多局限于用户空间运行，这不仅导致这些应用占用了大量的CPU资源，还限制了其性能表现。BPF提供了一种独特的替代方案，因为它作为内核虚拟机(VM)运行，支持在原本独立的内核空间中进行包过滤。

然而，尽管有创新，BPF最初并未得到广泛应用。随着计算机技术的进步，尤其是64位处理器的普及，BPF项目迎来了全新的发展机遇。在此期间，BPF经历了重大升级，原有的功能性限制被逐步突破。

这样，eBPF便应运而生，进一步拓宽了其在操作系统内核中执行安全、高效程序的能力。eBPF在多个方面拓展了BPF的概念：

1.与其前身不同，eBPF并不局限于Linux内核的网络子系统。它几乎可以访问Linux内核所能“关联”的任何资源。

2.BPF仅支持相对简单的、面向网络的操作，而eBPF配备了多种工具，可以扩展已开发程序的功能。

3.社区围绕eBPF做出了巨大的努力，产生了许多软件开发套件(SDK)和工具，极大地方便了eBPF程序的开发过程。

eBPF：内核的JavaScript可编程接口

对于浏览器来说，JavaScript的引入带来了可编程性，并引发了一场巨大的革命，将浏览器转变为几乎独立的操作系统。eBPF正逐渐扮演着类似JavaScript在浏览器中的角色，只不过这次是在操作系统内核层面。

Linux内核的主要目的是抽象化硬件或虚拟硬件，并提供一致的API（系统调用），使应用程序能够运行和共享资源。为了实现这一目标，内核由多个子系统组成，每个子系统负责不同的任务。子系统通常允许一定程度的配置以满足不同的用户需求。当所需的行为无法通过配置达成时，传统上有两种选择：一是修改内核源代码，此路径不仅耗时费力，还需历经社区审核；二是编写一个内核模块，虽相对灵活，但模块随内核迭代需定期修复。二者均非理想之选，前者成本高昂，后者牺牲了可移植性。

eBPF提供了一个新的选项，可以在不修改内核源代码或加载内核模块的情况下，重新编程Linux内核的行为，同时确保在不同内核版本间保持一定程度的行为一致性、兼容性和安全性。为此，eBPF程序也需要一个相应的API，允许用户定义的应用程序执行和共享资源。

换言之，从某种意义上说，eBPF虚拟机也提供了一个类似于系统调用的机制。借助eBPF与用户空间之间的通信机制，无论是WebAssembly虚拟机还是用户空间应用程序都能够全面利用这套“系统调用”。一方面，它可以通过编程方式扩展传统系统调用的能力；另一方面，它能够在网络、文件系统等多个层级实现更高效的可编程I/O处理，从而解锁内核级编程的全新潜能，推动操作系统内核进入一个更为灵活和动态的时代。

如上图所示，当今的Linux内核正在向新的内核模型演进：用户定义的应用程序既可在内核空间也可在用户空间运行，用户空间通过传统的系统调用来访问系统资源，而内核空间则通过BPFHelperCall与系统的各个部分交互。

截至2023年初，内核中的eBPF虚拟机已包含超过220个Helper系统接口，广泛覆盖了多种应用场景。值得注意的是，BPFHelperCall与系统调用并不具有竞争性。它们的编程模型和性能优势截然不同，无法完全互相替代。对于Wasm及WASI生态系统而言，情况类似。专门设计的wasi接口需经历漫长的标准化过程，然而，它可为特定场景下的用户模式应用程序提供更好的性能和可移植性保障。另一方面，eBPF则能提供一个快速灵活的系统接口扩展方案，同时确保沙箱特性和可移植性。

目前，eBPF仍处于发展的初级阶段，但已经展现出强大的潜力。凭借eBPF提供的内核接口及其与用户空间交互的能力，运行在Wasm虚拟机中的应用程序几乎能够访问任何内核或用户模式函数调用（如kprobe、uprobe等）的数据和返回值。它能以较低的成本收集并理解所有的系统调用，获取所有网络操作（如tracepoint、socke