经验首页 前端设计 程序设计 Java相关 移动开发 数据库/运维 软件/图像 大数据/云计算 其他经验
当前位置：技术经验 » 程序设计 » 编程经验 » 查看文章
【eBPF-02】入门：基于 BCC 框架的程序进阶
来源：cnblogs　　作者：_hong　　时间：2023/12/29 9:18:06　　对本文有异议

本文是 eBPF 系列的第二篇文章，我们来学习 eBPF BCC 框架的进阶用法，对上一篇文章中的代码进行升级，动态输出进程运行时的参数情况。

主要内容包括：

  1. 通过 kprobe 挂载内核事件的 eBPF 程序要如何编写？
  2. 通过 tracepoint 挂载内核事件的 eBPF 程序要如何编写？
  3. eBPF 的程序事件类型有哪些？

在开始之前，我们来回顾一下前一篇文章的内容。

前一篇文章介绍了如何通过 BCC 框架来编写一个简单的 eBPF 程序。在内核空间，使用 c 程序实现 eBPF 的核心逻辑；在用户空间，使用 python 脚本作为 eBPF 程序的控制、加载和展示。其中，内核态通过若干 eBPF helper 函数，获取内核观测数据，并通过 PERF 区域，将这些数据传递到用户空间；用户态使用attach_kprobe() 将内核 eBPF 函数绑定到某个内核事件上。

整个流程如下图所示：

image

在上面的实现过程中，用户态通过 kprobe 的方式，为某个内核事件挂载自定义处理逻辑（图中是指定了内核中 do_execve 函数）。通过这种方式，我们能够监测绝大部分的内核函数，这正是 eBPF 技术牛逼的原因。

对于这种 kprobe 类型的 eBPF 程序，我们再来看一个例子（改编自 Brendan Gregg 大神的 execsnoop 工具：https://github.com/iovisor/bcc/blob/master/tools/execsnoop.py ）

1 进程执行参数的监控

接下来，我们要对上图中的工具再次进行功能升级，我希望这个工具在运行时，能够输出当前执行进程的参数信息。

如果将 eBPF 程序等同于 C 程序来看，这个问题似乎没那么困难。何以见得？

1.1 分析

sys_execve 系统调用的函数签名为：int execve(const char *filename, char *const argv[], char *const envp[]), 其中，argv[]便记录了进程执行的参数。我们大可以像提取 filename 的方式那样，提取 argv[]，并将其传入到用户空间中。

但实际上，eBPF 程序与 C 程序并不等同。eBPF 编程中有 “两座大山” 般的限制，分别是：

限制一：eBPF 程序运行栈仅有 512 字节。

限制二：eBPF 程序可以调用的接口极其有限。

因此，如果我们想尝试在 512 字节的 eBPF 运行栈中完整拼接整理不定长的 argv[] 参数列表，是根本不可能的。

基于以上分析，本文给出一个比较合理的解决方案：

Q：如何防止运行栈爆栈？

1）既然运行栈有大小限制，不如直接将拼接操作转移到用户态完成。eBPF 程序只需要将 argv[] 数组中每个 argv 传输到用户态程序中。
2）对于长度过长的 argv，没办法了，只能手动截断了。

Q：用户态何时进行参数拼接？何时进行参数展示？

1）既然需要用户态完成拼接，那么，可以分为两个阶段。STEP-1，仅专注字符串的拼接；STEP-2，仅专注字符串展示。
2）对于 execve 系统调用，我们可以在 enter 时执行 STEP-1 操作，在 exit 是执行 STEP-2 操作。

接下来更新代码。

1.2 定义

首先，对于用于交互的结构体，增加两个个字段，其一用于记录 execve 调用的每个参数，其二用于记录 eBPF 执行的阶段；同时，去掉冗余字段 fname

  1. #define ARGSIZE     128
  2. #define MAXARG      60
  4. enum event_step {
  5. 	STEP_1,		// STEP 1: 执行 argv 拼接
  6. 	STEP_2,		// STEP 2: 执行 argv 展示
  7. };
  9. struct data_t {
  10. 	u32		pid;
  11. 	enum		event_step step;	// 记录 eBPF 执行阶段
  12. 	char		comm[TASK_COMM_LEN];
  13. 	char		argv[ARGSIZE];		// 记录每一个参数
  14. };

定义 BPF_PERF_OUTPUT：

  1. BPF_PERF_OUTPUT(events);

1.3 处理

实现 execve 系统调用 enter 和 exit 回调函数：

  1. // exter execve
  2. int syscall__execve(struct pt_regs *ctx, const char __user *filename,
  3. 			const char __user *const __user *__argv,
  4. 			const char __user *const __user *__envp) {
  5. 	struct data_t data = {};
  6. 	// 设置 step = STEP 1
  7. 	data.step = STEP_1;
  8. 	// 设置 pid
  9. 	data.pid = bpf_get_current_pid_tgid() >> 32;
  10. 	// 设置 comm
  11. 	bpf_get_current_comm(&data.comm, sizeof(data.comm));
  12. 	// 设置每一个 argv，并导出
  13. 	...
  14. 	
  15. 	return 0;
  16. }
  19. // exit execve
  20. int do_ret_sys_execve(struct pt_regs *ctx) {
  21. 	struct data_t data = {};
  22. 	// 设置 step = STEP 1
  23. 	data.step = STEP_2;
  24. 	// 设置 pid
  25. 	data.pid = bpf_get_current_pid_tgid() >> 32;
  26. 	// 设置 comm
  27. 	bpf_get_current_comm(&data.comm, sizeof(data.comm));
  28. 	// 提交 perf
  29. 	events.perf_submit(ctx, &data, sizeof(data));
  30.     return 0;
  31. }

注意，这里 bpf_get_current_pid_tgid() 辅助函数返回值高 32 为内核视角下的 process ID（用户视角下为 TID），低 32 位为内核视角下的 thread group ID（用户视角下的 PID）。这里右移 32 位，是获取用户视角的 PID。

1.4 绑定

用户态绑定 kprobe 事件：

  1. b = BPF(src_file="execsnoop.c")
  2. execve_fnname = b.get_syscall_fnname("execve")
  3. # enter 事件
  4. b.attach_kprobe(event=execve_fnname, fn_name="syscall__execve")
  5. # exit 事件
  6. b.attach_kretprobe(event=execve_fnname, fn_name="do_ret_sys_execve")

1.5 难点

内核态如何设置并导出每一个 argv[]？

  1. // 字符串提交
  2. static int __submit_arg(struct pt_regs *ctx, void *ptr, struct data_t *data) {
  3. 	// 提交 perf 之前，需要拷贝到用户态变量中
  4. 	bpf_probe_read_user(data->argv, sizeof(data->argv), ptr);
  5. 	// 将这个 argv 提交
  6. 	events.perf_submit(ctx, data, sizeof(struct data_t));
  7. 	return 1;
  8. }
  9. // 字符串控制
  10. static int submit_arg(struct pt_regs *ctx, void *ptr, struct data_t *data) {
  11. 	const char *argp = NULL;
  12. 	bpf_probe_read_user(&argp, sizeof(argp), ptr);
  13. 	// 是否到达末尾字符串
  14. 	if (argp) {
  15. 		return __submit_arg(ctx, (void *)(argp), data);
  16. 	}
  17. 	return 0;
  18. }
  20. int syscall__execve(struct pt_regs *ctx, const char __user *filename,
  21. 			const char __user *const __user *__argv,
  22. 			const char __user *const __user *__envp) {
  23. 	// 设置过程
  24. 	...
  25. 	// (A) 设置每一个 argv，并导出
  26. 	#pragma unroll
  27. 	for (int i = 1; i < MAXARG; i++) {
  28. 		if (submit_arg(ctx, (void *)&__argv[i], &data) == 0)
  29. 			goto out;
  30. 	}
  31. 	// (B) 如果当前的 argv[] 太长了，进行截断操作
  32. 	char ellipsis[] = "...";
  33. 	__submit_arg(ctx, (void *)ellipsis, &data);
  34. out:
  35. 	return 0;
  36. }

关注核心的两个步骤：

(A) MAXARG 代表一个 argv[] 的最大监测数量。首先要遍历这个 argv[] 的每一个字符串，如果这个字符不为 NULL（说明没有到当前 argv[] 结尾）或不超过最大值 MAXARG，那么将每个字符串提交到 PERF 区域。

注意：
低版本（5.3 以前）的 eBPF 程序不支持循环。5.3 版本后也仅支持有界循环。在低版本的 eBPF 中使用循环有一个小技巧，那就是通过 #pragma unroll 进行编译器循环展开预处理。

(B) 如果超过了这个最大数量 MAXARG，后面及时再有参数，也进行截断处理。

1.6 拼接

用户态获取和拼接参数列表是基于 eBPF 阶段的。

  1. from collections import defaultdict
  3. argv = defaultdict(list)
  4. class EventStep(object):
  5. 	STEP_1 = 0
  6. 	STEP_2 = 1
  8. # PERF 事件回调处理
  9. def print_event(cpu, data, size):
  10. 	event = b["events"].event(data)
  11. 	# STEP 1：拼接
  12. 	if event.step == EventStep.STEP_1:
  13. 		argv[event.pid].append(event.argv)
  14. 	# STEP 2：显示
  15. 	elif event.step == EventStep.STEP_2:
  16. 		argv_text = b' '.join(argv[event.pid]).replace(b'\n', b'\\n')
  17. 		printb(b"%-16s %-7d %s" % (event.comm, event.pid, argv_text))
  18. 		try:
  19. 			del(argv[event.pid])
  20. 		except Exception:
  21. 			pass
  23. # 绑定 PERF 事件回调处理
  24. b["events"].open_perf_buffer(print_event)
  25. while 1:
  26. 	try:
  27. 		b.perf_buffer_poll()
  28. 	except KeyboardInterrupt:
  29. 		exit()

用户态程序需要注意：event 事件通过 PERF 获取的结构数据为 Byte 类型，需要通过 decode('utf-8')/encode() 与 str 类型进行转换。

1.7 完整代码和运行效果

  1. // execsnoop.c
  2. #include <linux/sched.h>
  3. #include <linux/fs.h>
  5. #define ARGSIZE     128
  6. #define MAXARG      60
  7. enum event_step {
  8. 	STEP_1,
  9. 	STEP_2,
  10. };
  11. struct data_t {
  12. 	u32		pid;
  13. 	enum		event_step step;
  14. 	char		comm[TASK_COMM_LEN];
  15. 	char		argv[ARGSIZE];
  16. };
  17. BPF_PERF_OUTPUT(events);
  19. static int __submit_arg(struct pt_regs *ctx, void *ptr, struct data_t *data) {
  20. 	bpf_probe_read_user(data->argv, sizeof(data->argv), ptr);
  21. 	events.perf_submit(ctx, data, sizeof(struct data_t));
  22. 	return 1;
  23. }
  24. static int submit_arg(struct pt_regs *ctx, void *ptr, struct data_t *data) {
  25. 	const char *argp = NULL;
  26. 	bpf_probe_read_user(&argp, sizeof(argp), ptr);
  27. 	if (argp) {
  28. 		return __submit_arg(ctx, (void *)(argp), data);
  29. 	}
  30. 	return 0;
  31. }
  32. // exter execve
  33. int syscall__execve(struct pt_regs *ctx, const char __user *filename,
  34. 			const char __user *const __user *__argv,
  35. 			const char __user *const __user *__envp) {
  36. 	struct data_t data = {};
  37. 	data.step = STEP_1;
  38. 	data.pid = bpf_get_current_pid_tgid() >> 32;
  39. 	bpf_get_current_comm(&data.comm, sizeof(data.comm));
  40. 	#pragma unroll
  41. 	for (int i = 1; i < MAXARG; i++) {
  42. 		if (submit_arg(ctx, (void *)&__argv[i], &data) == 0)
  43. 			goto out;
  44. 	}
  45. 	char ellipsis[] = "...";
  46. 	__submit_arg(ctx, (void *)ellipsis, &data);
  47. out:
  48. 	return 0;
  49. }
  50. // exit execve
  51. int do_ret_sys_execve(struct pt_regs *ctx) {
  52. 	struct data_t data = {};
  53. 	data.step = STEP_2;
  54. 	data.pid = bpf_get_current_pid_tgid() >> 32;
  55. 	bpf_get_current_comm(&data.comm, sizeof(data.comm));
  56. 	events.perf_submit(ctx, &data, sizeof(data));
  57. 	return 0;
  58. }
  1. # execsnoop.py
  2. #!/usr/bin/python3
  3. from bcc import BPF
  4. from bcc.utils import printb
  5. from collections import defaultdict
  7. argv = defaultdict(list)
  8. class EventStep(object):
  9. 	STEP_1 = 0
  10. 	STEP_2 = 1
  12. b = BPF(src_file="execsnoop.c")
  13. execve_fnname = b.get_syscall_fnname("execve")
  14. b.attach_kprobe(event=execve_fnname, fn_name="syscall__execve")
  15. b.attach_kretprobe(event=execve_fnname, fn_name="do_ret_sys_execve")
  17. print("%-7s %-16s %s" % ("PID", "PCOMM", "ARGS"))
  19. # process event
  20. def print_event(cpu, data, size):
  21. 	event = b["events"].event(data)
  22. 	fname = ""
  23. 	if event.step == EventStep.STEP_1:
  24. 		argv[event.pid].append(event.argv)
  25. 	elif event.step == EventStep.STEP_2:
  26. 		argv_text = b' '.join(argv[event.pid]).replace(b'\n', b'\\n')
  27. 		printb(b"%-7d %-16s %s" % (event.pid, event.comm, argv_text))
  28. 		try:
  29. 			del(argv[event.pid])
  30. 		except Exception:
  31. 			pass
  33. # loop with callback to print_event
  34. b["events"].open_perf_buffer(print_event)
  35. while 1:
  36. 	try:
  37. 		b.perf_buffer_poll()
  38. 	except KeyboardInterrupt:
  39. 		exit()

运行效果：

image

2 Tracepoint 追踪点

前文提到过，kprobe 方式，几乎可以使 eBPF 挂载到内核中任意一个函数事件上，随着内核函数的执行而触发。但是，由于不同的内核版本，其某个具体函数的定义、参数和实现可能会有所不同（kprobe 实现的事件处理函数要求和挂载点函数拥有相同的参数）。因此，使用 kprobe 方式实现的 eBPF 程序可能无法在其他内核的主机上运行。此外，kprobe 无法挂载到静态函数或内联函数上。而出于性能考虑，大部分网络相关的内层函数都是内联或者静态的，因此，kprobe 方式在这些领域也只能望洋兴叹了。

上述两点，均为 kprobe 方式的局限性，它并不具备很好的可移植性。于是，从 Linux 内核 4.7 开始，能让 eBPF 使用的 tracepoint 出现了（官方文档）。tracepoint 是由内核开发人员在代码中设置的静态 hook 点，具有稳定的 API 接口，不会随着内核版本的变化而变化。但由于 tracepoint 是需要内核研发人员参数编写，其数量有限，并不是所有的内核函数中都具有类似的跟踪点，所以从灵活性上不如 kprobes 这种方式。

2.1 kprobe 和 tracepoint 对比

在 3.10 内核中，kprobe 与 tracepoint 方式对比如下：

内容 kprobe tracepoint
追踪类型 动态 静态
Hook 点数量 100000+ 1200+
稳定的 API 否 是

可以使用以下命令查看系统支持的 tracepoint，支持 grep 检索。

  1. perf list
  2. perf list | grep execve

image

上面的执行结果可以看到，execve系统调用具有两个 syscalls 类型的静态跟踪点，并且，tracepoint 已经对 enter 和 exit 做了区分，其功能基本等同于 kprobe/kretprobe。

在使用 tracepoint 之前，我们需要了解 tracepoint 相关参数的格式。syscalls:sys_enter_execve 格式定义在 /sys/kernel/debug/tracing/events/syscalls/sys_enter_execve/format 文件中。

  1. # 查看 syscalls:sys_enter_execve 参数
  2. cat /sys/kernel/debug/tracing/events/syscalls/sys_enter_execve/format

2.2 重构代码

接下来，使用 tracepoint 方式重构第 1 节的代码，如下：

  1. // execsnoop.c
  2. #include <linux/sched.h>
  3. #include <linux/fs.h>
  5. #define ARGSIZE         128
  6. #define MAXARG          60
  8. enum event_step {
  9. 	STEP_1,
  10. 	STEP_2,
  11. };
  12. struct data_t {
  13. 	u32 pid;
  14. 	char comm[TASK_COMM_LEN];
  15. 	enum event_step step;
  16. 	char argv[ARGSIZE];
  17. };
  18. BPF_PERF_OUTPUT(events);
  19. static int __submit_arg(struct pt_regs *ctx, void *ptr, struct data_t *data) {
  20. 	bpf_probe_read_user(data->argv, sizeof(data->argv), ptr);
  21. 	events.perf_submit(ctx, data, sizeof(struct data_t));
  22. 	return 1;
  23. }
  24. static int submit_arg(struct pt_regs *ctx, void *ptr, struct data_t *data) {
  25. 	const char *argp = NULL;
  26. 	bpf_probe_read_user(&argp, sizeof(argp), ptr);
  27. 	if (argp) {
  28. 		return __submit_arg(ctx, (void *)(argp), data);
  29. 	}
  30. 	return 0;
  31. }
  32. // (A) sys_enter_execve tracepoint
  33. TRACEPOINT_PROBE(syscalls, sys_enter_execve) {
  34. 	struct data_t data = {};
  35. 	const char **argv = (const char **) (args->argv);
  36. 	
  37. 	data.step = STEP_1;
  38. 	data.pid = bpf_get_current_pid_tgid() >> 32;
  39. 	bpf_get_current_comm(&data.comm, sizeof(data.comm));
  41. 	#pragma unroll
  42. 	for (int i = 1; i < MAXARG; i++) {
  43. 		// (B) args 强制转换为 ctx
  44. 		if (submit_arg((struct pt_regs *)args, (void *)&argv[i], &data) == 0)
  45. 			goto out;
  46. 	}
  47. 	char ellipsis[] = "...";
  48. 	__submit_arg((struct pt_regs *)args, (void *)ellipsis, &data);
  49. out:
  50. 	return 0;
  51. }
  52. // sys_exit_execve tracepoint
  53. TRACEPOINT_PROBE(syscalls, sys_exit_execve) {
  54. 	struct data_t data = {};
  55. 	data.step = STEP_2;
  56. 	data.pid = bpf_get_current_pid_tgid() >> 32;
  57. 	bpf_get_current_comm(&data.comm, sizeof(data.comm));
  59. 	events.perf_submit(args, &data, sizeof(data));
  60. 	return 0;
  61. }
  1. # execsnoop.py
  2. #!/usr/bin/python3
  3. from bcc import BPF
  4. from bcc.utils import printb
  5. from collections import defaultdict
  7. argv = defaultdict(list)
  8. class EventStep(object):
  9. 	STEP_1 = 0
  10. 	STEP_2 = 1
  12. # (C) 不再通过 kprobe 绑定 
  13. b = BPF(src_file="execsnoop.c")
  14. print("%-7s %-16s %s" % ("PID", "PCOMM", "ARGS"))
  16. # process event
  17. def print_event(cpu, data, size):
  18. 	event = b["events"].event(data)
  19. 	if event.step == EventStep.STEP_1:
  20. 		argv[event.pid].append(event.argv)
  21. 	elif event.step == EventStep.STEP_2:
  22. 		argv_text = b' '.join(argv[event.pid]).replace(b'\n', b'\\n')
  23. 		printb(b"%-7d %-16s %s" % (event.pid, event.comm, argv_text))
  24. 		try:
  25. 			del(argv[event.pid])
  26. 		except Exception:
  27. 			pass
  29. # loop with callback to print_event
  30. b["events"].open_perf_buffer(print_event)
  31. while 1:
  32. 	try:
  33. 		b.perf_buffer_poll()
  34. 	except KeyboardInterrupt:
  35. 		exit()

注意：

A）一个 tracepoint 定义接收两个参数，TRACEPOINT_PROBE(syscalls, sys_enter_execve) 第一个为子系统名称，第二个为事件名称。

B）tracepoint 中的所有参数都会包含在一个固定名称的 args 的结构体中。args 类型为 struct tracepoint__syscalls__sys_enter_open，其第一个字段为 u64 __do_not_use__;，该字段为 ctx 的保留位置。因此，args 可以被强制转换为 ctx。

ctx 是啥？

在《Linux 内核观测技术 BPF》一书中，ctx被称为“上下文”，提供了访问内核正在处理的信息。我们可以通过 PT_REGS_RC(ctx) 来获取当前函数的返回值。

C）用户态代码不再需要 attach_kprobe 手动绑定。

3 eBPF 程序事件类型

像是 kprobe、tracepoint 将 eBPF 程序挂载到内核事件的方式，可以暂且被称为 eBPF 事件类型。事实上，除了以上列出的两种，eBPF 事件类型还有很多，选取其中一些列举如下：

  • kprobes/kretprobes：内核函数事件。不再赘述。
  • tracepoint：内核跟踪点事件。不再赘述。
  • uprobes/uretprobes：用户空间函数事件，可以绑定监听一个用户空间的函数。
  • USDT probes：用户自定义的静态追踪点。用户可以在用户空间的程序中插入静态追踪点，用于挂载 eBPF。
  • LSM Probes：LSM Hook 挂载点。需要内核版本 5.7 以上。

由于篇幅限制，不再列举其他 eBPF 事件类型了，后面如果有精力，再补一篇文章。

4 总结

本文在前一篇文章的基础上，对进程执行监控工具（execsnoop）进行了升级，实时打印进程执行时传入的参数列表；并通过 kprobe 和 tracepoint 两种方式，绑定 eBPF 程序，给出了代码实现。同时，对这两种 eBPF 事件类型进行了简单比较。显然，在你手动开发一个 eBPF 程序时，建议使用 tracepoint，以追求更好的稳定性和可移植性。文章的最后，简单列出了一些支持的 eBPF 事件类型。

以上抛砖引玉，如有不正确指出，请大家及时斧正。如果你喜欢这篇文章，请点个推荐吧！

原文链接：https://www.cnblogs.com/lianyihong/p/17932675.html

 友情链接：直通硅谷 　点职佳 　北美留学生论坛

编程经验热门文章

  • Prometheus监控之SNMP Exporter介绍和数据展现
  • Intel 82599网卡异常挂死原因
  • 腾讯防水墙的分析识别与破解
  • 桌面应用自动化WinAppDriver入门
  • 文档在线预览（三）使用js前端实现word、excel、pdf、ppt 在线预览
  • 「教程」如何下载AcFun网站上的视频、A站视频下载工具
  • 基于Hi3559AV100的SVP(NNIE)开发整体流程
  • GBDT(梯度提升树)scikit-klearn中的参数说明及简汇
  • antd之RangePicker设置默认值方式
  • 决胜经典算法之插入排序

    • 编程经验推荐文章

  • wifi基础(一)：无线电波与WIFI信号干扰、衰减
  • 甲方扔给两个存在包名与类名均相同的Jar包，要在工程中同时使用怎么办？
  • 《花100块做个摸鱼小网站! 》第三篇—热搜表结构设计和热搜数据存储
  • Fluent Editor：一个基于 Quill 2.0 的富文本编辑器，功能强大、开箱即用！
  • 方法的三种调用形式
  • 《花100块做个摸鱼小网站! 》第二篇—后端应用搭建和完成第一个爬虫
  • 《熬夜整理》保姆级系列教程-玩转Wireshark抓包神器教程(4)-再识Wireshark - 北京-宏哥
  • 《软件性能测试分析与调优实践之路》(第2版) 读书笔记（二）总体介绍（下）-真正从性能分析与调优来看性能测试
  • 架构知识点（三）
  • 《花100块做个摸鱼小网站! 》第一篇—买云服务器和初始化环境

    • 本站QQ群：前端 618073944 | Java 606181507 | Python 626812652 | C/C++ 612253063 | 微信 634508462 | 苹果 692586424 | C#/.net 182808419 | PHP 305140648 | 运维 608723728

    W3xue 的所有内容仅供测试，对任何法律问题及风险不承担任何责任。通过使用本站内容随之而来的风险与本站无关。
    关于我们  |  意见建议  |  捐助我们  |  报错有奖  |  广告合作、友情链接（目前9元/月）请联系QQ：27243702 沸活量
    皖ICP备17017327号-2　皖公网安备34020702000426号