这是一个基于 CO-RE
(一次编译,到处运行)的 libbpf
的 eBPF 的开发教程,提供了从入门到进阶的 eBPF 开发实践指南,包括基本概念、代码实例、实际应用等内容。我们主要提供了一些 eBPF 工具的案例,帮助开发者学习 eBPF 的开发方法和技巧。教程内容可以在目录中找到,每个目录都是一个独立的 eBPF 工具案例。
在学习 eBPF 的过程中,我们受到了 tutorial_bcc_python_developer 的许多启发和帮助,但从 2022 年的角度出发,使用 libbpf 开发 eBPF 的应用是目前相对更好的选择。但目前似乎很少有基于 libbpf 和 BPF CO-RE 出发的、通过案例和工具介绍 eBPF 开发的教程,因此我们发起了这个项目。
本项目主要基于 libbpf-boostrap 和 eunomia-bpf 两个框架完成,并使用 eunomia-bpf 帮助简化一部分 libbpf eBPF 用户态代码的编写。
教程主要关注于可观察性,并简要介绍了 eBPF 的其他应用,例如网络、安全等等。
教程的详细文档可以在这里找到:
- https://github.com/yunwei37/bpf-developer-tutorial
- https://gitee.com/yunwei37/bpf-developer-tutorial/tree/main
让 chatGPT 来帮助我们
本教程大部分内容由 chatGPT 生成,我们尝试教会 chatGPT 编写 eBPF 程序:
- 告诉它基本的 eBPF 编程相关的常识
- 告诉它一些案例:hello world,eBPF 程序的基本结构,如何使用 eBPF 程序进行追踪,并且让它开始编写教程
- 手动调整教程,并纠正代码和文档中的错误
- 把修改后的代码再喂给 chatGPT,让它继续学习
- 尝试让 chatGPT 自动生成 eBPF 程序和对应的教程文档!例如
完整的对话记录可以在这里找到: chatGPT.md
目录
- lesson 0-introduce 介绍 eBPF 的基本概念和常见的开发工具
- lesson 1-helloworld 使用 eBPF 开发最简单的「Hello World」程序,介绍 eBPF 的基本框架和开发流程
- lesson 2-kprobe-unlink 在 eBPF 中使用 kprobe 捕获 unlink 系统调用
- lesson 3-fentry-unlink 在 eBPF 中使用 fentry 捕获 unlink 系统调用
- lesson 4-opensnoop 使用 eBPF 捕获进程打开文件的系统调用集合,使用全局变量在 eBPF 中过滤进程 pid
- lesson 5-uprobe-bashreadline 在 eBPF 中使用 uprobe 捕获 bash 的 readline 函数调用
- lesson 6-sigsnoop 捕获进程发送信号的系统调用集合,使用 hash map 保存状态
- lesson 7-execsnoop 捕获进程执行时间,通过 perf event array 向用户态打印输出
- lesson 8-execsnoop 捕获进程退出事件,使用 ring buffer 向用户态打印输出
- lesson 9-runqlat 捕获进程调度延迟,以直方图方式记录
- lesson 10-hardirqs 使用 hardirqs 或 softirqs 捕获中断事件
- lesson 11-bootstrap 使用 libbpf-boostrap 为 eBPF 编写原生的的用户态代码
- lesson 12-profile 使用 eBPF 进行性能分析
- lesson 13-tcpconnlat 记录 TCP 连接延迟
- lesson 14-tcpstates 记录 TCP 连接状态
- lesson 15-tcprtt 以直方图方式记录 TCP RTT
- lesson 16-memleak 检测内存泄漏
- lesson 17-biopattern 捕获磁盘 IO 模式
- lesson 18-further-reading 更进一步的相关资料?
- lesson 19-lsm-connect 使用 LSM 进行安全检测防御
- lesson 20-tc 使用 eBPF 进行 tc 流量控制
- lesson 21-xdp 使用 eBPF 进行 XDP 报文处理
为什么需要基于 libbpf 和 BPF CO-RE 的教程?
历史上,当需要开发一个BPF应用时可以选择BCC 框架,在实现各种用于Tracepoints的BPF程序时需要将BPF程序加载到内核中。BCC提供了内置的Clang编译器,可以在运行时编译BPF代码,并将其定制为符合特定主机内核的程序。这是在不断变化的内核内部下开发可维护的BPF应用程序的唯一方法。在BPF的可移植性和CO-RE一文中详细介绍了为什么会这样,以及为什么BCC是之前唯一的可行方式,此外还解释了为什么 libbpf 是目前比较好的选择。去年,Libbpf的功能和复杂性得到了重大提升,消除了与BCC之间的很多差异(特别是对Tracepoints应用来说),并增加了很多BCC不支持的新的且强大的特性(如全局变量和BPF skeletons)。
诚然,BCC会竭尽全力简化BPF开发人员的工作,但有时在获取便利性的同时也增加了问题定位和修复的困难度。用户必须记住其命名规范以及自动生成的用于Tracepoints的结构体,且必须依赖这些代码的重写来读取内核数据和获取kprobe参数。当使用BPF map时,需要编写一个半面向对象的C代码,这与内核中发生的情况并不完全匹配。除此之外,BCC使得用户在用户空间编写了大量样板代码,且需要手动配置最琐碎的部分。
如上所述,BCC依赖运行时编译,且本身嵌入了庞大的LLVM/Clang库,由于这些原因,BCC与理想的使用有一定差距:
- 编译时的高资源利用率(内存和CPU),在繁忙的服务器上时有可能干扰主流程。
- 依赖内核头文件包,不得不在每台目标主机上进行安装。即使这样,如果需要某些没有通过公共头文件暴露的内核内容时,需要将类型定义拷贝黏贴到BPF代码中,通过这种方式达成目的。
- 即使是很小的编译时错误也只能在运行时被检测到,之后不得不重新编译并重启用户层的应用;这大大影响了开发的迭代时间(并增加了挫败感…)
Libbpf + BPF CO-RE (Compile Once – Run Everywhere) 选择了一个不同的方式,其思想在于将BPF程序视为一个普通的用户空间的程序:仅需要将其编译成一些小的二进制,然后不用经过修改就可以部署到目的主机上。libbpf扮演了BPF程序的加载器,负责配置工作(重定位,加载和校验BPF程序,创建BPF maps,附加到BPF钩子上等),开发者仅需要关注BPF程序的正确性和性能即可。这种方式使得开销降到了最低,消除了大量依赖,提升了整体开发者的开发体验。
在API和代码约定方面,libbpf坚持"最少意外"的哲学,即大部分内容都需要明确地阐述:不会隐含任何头文件,也不会重写代码。仅使用简单的C代码和适当的辅助宏即可消除大部分单调的环节。 此外,用户编写的是需要执行的内容,BPF应用程序的结构是一对一的,最终由内核验证并执行。
参考:BCC 到libbpf 的转换指南【译】 - 深入浅出eBPF: https://www.ebpf.top/post/bcc-to-libbpf-guid/
eunomia-bpf
eunomia-bpf 是一个开源的 eBPF 动态加载运行时和开发工具链,是为了简化 eBPF 程序的开发、构建、分发、运行而设计的,基于 libbpf 的 CO-RE 轻量级开发框架。
使用 eunomia-bpf ,可以:
- 在编写 eBPF 程序或工具时只编写 libbpf 内核态代码,自动获取内核态导出信息;
- 使用 WASM 进行用户态交互程序的开发,在 WASM 虚拟机内部控制整个 eBPF 程序的加载和执行,以及处理相关数据;
- eunomia-bpf 可以将预编译的 eBPF 程序打包为通用的 JSON 或 WASM 模块,跨架构和内核版本进行分发,无需重新编译即可动态加载运行。
eunomia-bpf 由一个编译工具链和一个运行时库组成, 对比传统的 BCC、原生 libbpf 等框架,大幅简化了 eBPF 程序的开发流程,在大多数时候只需编写内核态代码,即可轻松构建、打包、发布完整的 eBPF 应用,同时内核态 eBPF 代码保证和主流的 libbpf, libbpfgo, libbpf-rs 等开发框架的 100% 兼容性。需要编写用户态代码的时候,也可以借助 Webassembly 实现通过多种语言进行用户态开发。和 bpftrace 等脚本工具相比, eunomia-bpf 保留了类似的便捷性, 同时不仅局限于 trace 方面, 可以用于更多的场景, 如网络、安全等等。
- eunomia-bpf 项目 Github 地址: https://github.com/eunomia-bpf/eunomia-bpf
- gitee 镜像: https://gitee.com/anolis/eunomia