BPF_KPROBE宏提供了系统调用参数的意外值

Question

在使用libbpf引导程序时，我收到了kprobe系统调用的意外(奇怪(函数参数。例如，对于带有int close(inf fd)签名的close系统调用上的kprobe，我得到了像fd=15761240这样的巨大fd值，而预期的是像fd=4这样的小int。在Debian 11 x64 (kernel 5.10.0-7-amd64)和Ubuntu 21.10 x64 (kernel ~5.13)上复制了这一点。

调试代码：

#include "vmlinux.h"
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_tracing.h>
#include <bpf/bpf_core_read.h>
char LICENSE[] SEC("license") = "Dual BSD/GPL";
// accept4 syscall
// int accept4(int sockfd, struct sockaddr *restrict addr, socklen_t *restrict addrlen);
SEC("kretprobe/__x64_sys_accept4")
int BPF_KRETPROBE(accept, int ret) {
u64 id = bpf_get_current_pid_tgid();
u32 pid = id >> 32;
// filter specific pid for simplicity
if (pid != 31114 || ret < 0) {
return 0;
}
// debug returned file descriptor
bpf_printk("opened pid=%d fd=%d", pid, ret);
return 0;
}
// close syscall
// int close(int fd);
SEC("kprobe/__x64_sys_close")
int BPF_KPROBE(close, int fd) {
u64 id = bpf_get_current_pid_tgid();
u32 pid = id >> 32;
// filter specific pid for simplicity
if (pid != 31114) {
return 0;
}
// debug fd arg (expected to be equal to fd returned on accept4)
bpf_printk("closed pid=%d fd=%d", pid, fd);
return 0;
}

结果(见fd=4与fd=15761240的意外差异(：

$ cat /sys/kernel/debug/tracing/trace_pipe
main-31114   [001] d...  9069.254408: bpf_trace_printk: opened pid=31114 fd=4
main-31114   [001] d...  9069.321946: bpf_trace_printk: closed pid=31114 fd=15761240

我尝试更改CCD_ 10：首先使用libbbpf bootstrap提供的CCD_；"本地"；来自实例操作系统内核的vmlinux.h，在这两种方式上我都得到了上面的问题。

还尝试以BCC方式运行相同的bpf程序(在运行时使用BCC编译(，并在没有bpf_KPROBE宏的情况下声明kprobes，如下所示：

int syscall__probe_close_entry(struct pt_regs *ctx, int fd) { ... }

并且它在所有调试点都如预期的那样工作：CCD_ 13。是BPF_KPROBE宏错误/与内核不兼容，还是我遗漏了什么？

Answer 1

由@anakryiko在此处解决

__x64_sys_close()实际上只有一个输入参数，那就是struct pt_regs *，它包含所有的系统调用输入参数。所以你必须这样做才能访问输入参数：

SEC("kprobe/__x64_sys_close")
int BPF_KPROBE(do_sys_close, struct pt_regs *regs)
{
pid_t pid;
int fd;
fd = PT_REGS_PARM1_CORE(regs);
pid = bpf_get_current_pid_tgid() >> 32;
bpf_printk("KPROBE ENTRY pid = %d, fd = %dn", pid, fd);
return 0;
}

添加特定于系统调用的kprobe/kretprobe宏可能是个好主意，因为这是一个常见的问题。添加了libbpf/libbpf#425来跟踪这一点。