目录
libbpf-bootstrap
代码结构介绍
用户层函数
编译
查看
生成内核层的.o文件
第一模块
第二模块
第三模块
第四模块
第五模块
生成辅助文件(.skel.h)
介绍
示例
生成代码层的.o文件
第一模块
第二模块
第三模块
链接出可执行文件
后续+总结
libbpf-bootstrap
代码结构介绍
ebpf代码一般分为两个部分,用户层代码(.c)和内核层代码(.bpf.c)
- 内核层代码：跑在内核层，负责实现真正的eBPF功能(也就是核心功能代码)
- 用户层代码：跑在用户层，负责 open, load, attach eBPF内核层代码到内核，并负责用户层和内核层的数据交互
用户层函数
- 注意,在用户层写的代码中,我们使用的核心函数其实是经过了进一步封装的(函数名+功能名):
- 他们的函数名第一个都是程序名,这么自定义的行为说明底层绝对是调用了其他函数,但我们在使用时并不需要关心,因为肯定是库自发性的行为
- (当然啦,学习的时候还是要懂原理的,将在下面的编译里介绍)
编译
查看
我们可以通过现成的makefile来查看编译时的具体语句:
make kprobe V=1
生成内核层的.o文件
我们先看生成了内核层的.o文件的编译语句:
clang -g -O2 -target bpf -D__TARGET_ARCH_x86 -I.output -I../../libbpf/include/uapi -I../../vmlinux/x86/ -I/libbpf-bootstrap/blazesym/capi/include -idirafter /usr/local/include -idirafter /usr/lib/llvm-11/lib/clang/11.0.0/include -idirafter /usr/include/x86_64-linux-gnu -idirafter /usr/include -c kprobe.bpf.c -o .output/kprobe.tmp.bpf.o /libbpf-bootstrap/examples/c/.output/bpftool/bootstrap/bpftool gen object .output/kprobe.bpf.o .output/kprobe.tmp.bpf.o
我们把这里的编译语句分为五部分:
第一模块
基本信息+功能选项
第二模块
添加libbpf-bootstrap库中的文件到搜索路径中
第三模块
添加系统库文件到搜索路径中
- -I和-idirafter的区别:
第四模块
指定要生成的目标文件
第五模块
使用bptool工具生成两份bpf.o文件(编译成 eBPF 字节码,字节码用elf格式存储)
- 一份用于生成辅助文件,以及加载到内核中
- 一份备份文件
- (根据实际语句理解的,应该是这样)
生成辅助文件(.skel.h)
介绍
/libbpf-bootstrap/examples/c/.output/bpftool/bootstrap/bpftool gen skeleton .output/kprobe.bpf.o > .output/kprobe.skel.h
还记得前面说的,用户层使用的函数其实是再次经过封装的吗?
- 是由bpftool工具自动帮我们根据.bpf.o来生成.skel.h头文件的
- 根据实际要在内核中执行的功能,根据执行过程需要的函数,生成一份用户层和内核层的中间文件
- 它提供了用户层的接口,并且自动在里面封装出可以执行内核层代码的代码
- 官方一点就是它里面包含了.bpf.c 对应的elf文件数据，以及用户层需要的 open, load, attach 等接口
示例
- 就像这样,他帮我们自动生成用户层接口,并在里面调用所需的libbpf中的函数,并进行一定处理:
- 这个更是如此,甚至将两个函数合在一块,方便我们使用:
- 如果追根溯源的话,更能体现它会根据内核层代码,建立中间要使用的数据结构,生成中间代码,生成用户层接口:
- 让我们一起说,谢谢它!!!
- 但是,这样也会导致用户层代码无法复用(因为每个接口的名字都是独立的)
生成代码层的.o文件
cc -g -Wall -I.output -I../../libbpf/include/uapi -I../../vmlinux/x86/ -I/libbpf-bootstrap/blazesym/capi/include -c kprobe.c -o .output/kprobe.o
和内核层的类似,我们可以把它分成三部分:
第一模块
普通选项
第二模块
添加搜索路径
- 添加.output是因为,有生成的.skel.h头文件在那个目录下
- 我们必须加上实际的库函数,才能编译成功
第三模块
指定目标文件名
链接出可执行文件
cc -g -Wall .output/kprobe.o /libbpf-bootstrap/examples/c/.output/libbpf.a -lelf -lz -o kprobe
后续+总结
可以看到,用户层代码.o文件+库文件最终链接出了可执行文件
那.bpf.o呢?
我是这么理解的 :
用户层代码用于管理ebpf程序的执行(启动啦,挂接啦,销毁啦等等)
而内核层代码只负责编写挂接后的操作(或者说核心操作),然后被加载到内核中,等待被触发:
- 可以看到,在libbpf库中,提供了一系列函数,用于将ebpf码传进系统调用函数中
- 也就说,.bpf.o并不在可执行文件里,而是被加载进了内核里,由可执行文件远程控制它的生命周期
- 然后就等待其被触发
并且经过一系列安全检查,保证这份程序被加载进内核前是安全的:
- 这个安全检查是利用了ebpf的特性编写的
- 在进入vts_write函数之前,先进行数组检查
- 如果越界,内核就可以在实际执行之前拒绝它
总之,它形成了一系列的关系:
.bpf.c文件 -> ebpf码 -> 加载进内核中 -> 等待被触发
-> skel.h头文件 -> 提供用户层接口 -> 在.c文件中被调用 -> 控制ebpf程序的执行流程
.c文件+.skel.h文件 -> 可执行文件
