对于理解eBPF程序在内核中的加载，检查，编译阶段等很有意义。

verfier：eBPF的一个验证器，实现了一个本模块下的CFI/CFG（控制流完整性）机制。

jit：Just-In-Time，即时编译，eBPF汇编会在内核中被规则替换成真正的x64的指令。

eBPF汇编中有r0至r10一共11个寄存器，作用如下：

所有的eBPF汇编在内核中定义为一个 struct bpf_insn ，当我们需要写的时候一般将连续的指令布置成一个结构体数组：

然后通过内核态的：bpf_prog_load 载入，编译，运行。

更具体的，在用户态可以定义辅助函数：

而内核中对应的处理函数就是：

相应的，struct bpf_prog 此结构体用于维护一个内核中的eBPF程序：

此函数中主要做了如下关键的事情：

单bpf函数调用 bpf_prog_select_runtime(prog,&err) jit编译prog。多bpf函数的prog调用jit_subprog。两者都会统一到针对do_jit的调用。

为编译后的prog分配一个唯一的id，bpftools会用到这个id。

入口位置在：

本函数是verifier的主要函数，可以看作一个eBPF-扩展CFI机制

主要做了如下操作：

函数主要目的：

主要流程如下：

首先取出env中保存的insn指令和长度。

调用 bpf_prog_calc_tag ，在其中算了一下SHA1，然后把算好的摘要放进env->prog->tag 中。值得注意的是函数中有这么几行：

```c
int bpf_prog_calc_tag(struct bpf_prog fp)
{
......
bool was_ld_map;
struct bpf_insn dst;
u8 raw, todo;
......
raw = vmalloc(raw_size);

......
/* We need to take out the map fd for the digest calculation

}

c. 如果检测到was_ld_map = true 已经设置，且对应的insn结构体都为空，即加载map指令的下一条指令。重新设置 was_ld_map = false 立即数为0 。

d. 也就是说，加载map指令和其下一条指令实际上是构成了一个整体，我们可以看一下对应的eBPF汇编：

也就是说，加载map的指令后面是跟了一条空指令的。作为padding。

for循环中扫描每一条指令。

如果是内存加载（BPF_LDX），必须保证带有BPF_MEM，并且立即数为0 。

如果是内存存储（BPF_STX），必须保证带有BPF_MEM，并且立即数为0 。

如果是：BPF_LD_IMM64_RAW ，标志为：.code = BPF_LD | BPF_DW | BPF_IMM 。即 BPF_LD_MAP_FD ，此时的code是加载map的操作。

如果此时是最后一条指令 ｜｜ 下一条指令不是空指令，abort。

如果当前load_map指令的src为0，即map_fd为0，跳过。

如果当前指令的src_reg，不是BPF_PSEUDO_MAP_FD，不是BPF_PSEUDO_MAP_VALUE；或者是BPF_PSEUDO_MAP_FD但下一条指令imm不为空。abort，其中BPF_PSEUDO_MAP_FD被条件define为1 。

check结束，通过 insn[0].imm 拿到fd，然__bpf_map_get转换为对应的bpf_map的地址。判断地址合法性。赋值给map。

check_map_prog_compatibility 检测与相应环境的兼容性。

如果设置了BPF_PSEUDO_MAP_FD标志，那么直接将刚刚iv.中取到的map赋值给addr。

否则，通过下一条指令的imm作为off，配合虚表中的 map_direct_value_addr 。主要实现在：array_map_direct_value_addr ，被用于bpf_array中获取到第一个value。value的地址赋值给addr。然后addr+=off。

以上实际就是为了取addr。

重新设置当前指令的imm为addr的低32位。而addr的高32位存储在下一条指令中。

检查当前map是否处于used状态。

使用 bpf_map_inc(map) ，当前map引用计数+1 。主要是为了拿住map，如果此map被verifier拒绝，那么调用release_maps释放，或者此map被其他有效的程序使用，直到此map被卸载（所有的map都在free_used_maps()中被释放）

将此map标记为used，添加进 env->used_maps表中。同时used_map_cnt计数器+1 。

如果当前的map是一个cgroup存储。进行检测，是否每个type只有一个对应的cgroup stroge。

insn++，i++，开始扫描下一条指令。

如果当前指令不是加载map的指令。调用 bpf_opcode_in_insntable 进行基本的指令unkown判断。

a. 首先初始化一个16*16的bool矩阵 public_insntable

b. BPF_INSN_MAP中存储的是合法的指令。通过 BPF_INSN_MAP(BPF_INSN_2_TBL, BPF_INSN_3_TBL) 配合，相当于将合法的指令映射到public_insntable 矩阵（向量）的某个位置，然后将其设置为true。

c. 然后再补充6条额外的合法指令，设置其在BPF_INSN_MAP上的位置位true。

d. 返回当前的指令code，在BPF_INSN_MAP位置上的bool标志。如果为true则通过检查，如果为false就abort。

注意，此时进行的只是一个最简单的指令（操作码）合法性检查。

函数主要目的：

函数主要流程：

调用 add_subprog(env,0) ，首先在 env->subprog_info 数组中二分查找off=0，此时查找失败，return -ENOENT，因为此时数组中还没有任何元素。接下来将新的off=0，插入到数组第一项的start成员中：env->subprog_info[env-。>subprog_cnt++].start = off ，最后进行排序。

通过for循环扫描insn[]。

在subprog[] 数组的最后一项补充一个insn_cnt。

subprog[env->subprog_cnt].start = insn_cnt;

接下来检测所有的跳转指令都在同一个 subprog中。

ps：根据别的师傅的解释：

bpf指令支持两种call调用，一种bpf函数对bpf函数的调用，一种是bpf中对内核helper func的调用。前者是指令class为BPF_JMP，指令opcode位BPF_CALL，并且src寄存器为BPF_PSEUDO_CALL，指令imm为callee函数到本指令的距离。另外一种是对对内核helper func的调用，指令class为特征是BPF_JMP，指令opcode为BPF_CALL，并且src_reg=0，指令imm在jit之前位内核helper func id，jit之后为对应的func到本指令的距离。

我这里遇到的主要是第二种。

函数主要目的：

非递归的深度优先遍历检测是否存在有向无环图（循环）

检测控制流合法性。

函数流程：

本函数中，首先通过DFS转换成执行流tree。在这里图上的边edge被分成四种情况：

同样的，图中的点也有几种情况：

非递归的DFS大致流程如下：

函数实现如下：

值得注意的是其中有一个一直出现的函数：init_explored_state

我这里找到了一个commit。

https://zh.osdn.net/projects/android-x86/scm/git/kernel/commits/5762a20b11ef261ae8436868555fab4340cb3ca0

Convert explored_states array into hash table and use simple hash
to reduce verifier peak memory consumption for programs with bpf2bpf
calls. More details in patch 3.

为了减少bpf到bpf的函数调用的峰值内存消耗，设置了对应结点的prune_point为true。

函数主要目的：

函数实现如下：

在 do_check_subprogs中会对每个没有设置 BTF_FUNC_GLOBAL 的subprog调用do_check_common进行检查。

函数主要目的：

函数中主要涉及的结构：

bpf_verifier_state

branch字段代表的是剩余探索的分支数量。

branch = 0，从这个状态出发的所有可能路径都达到了bpf_exit，或者已经被修剪了。

branch = 1，至少有一条路径正在被探索，这个状态还没有达到bpf_exit。

branch = 2，至少有两条路径正在被探索，这个状态是两个子节点的直接父节点。

其中一个是FALLTHROUGH也就是顺序执行的状态树边。另一个（稍后将被explored的）状态也被压入栈中，也有branch=1。他的父状态结点也有branch=1。

举个例子如果我们通过if的一条路径走到bpf_exit了，会调用update_branch_counts() 回溯更新每个状态树节点branches的值。if的分支节点之间通过 struct bpf_verifier_state *parent; 指针相连。

bpf_reg_state：维护了BPF寄存器的状态。

bpf_reg_type

struct tnum

当reg是一个具体的数值（范围值），本结构代表真正的值。

当reg是一个指针，这代表了到被指向对象的偏移量。

bpf_stack_slot_type

函数主要流程：

初始化当前state信息：

初始化函数状态与寄存器。

在 init_func_state 中，调用了 init_reg_state 来初始化寄存器。

如果设置了 env->prog->type == BPF_PROG_TYPE_EXT 调用btf_prepare_func_args 对func的参数类型进行转换与检查。转换成PTR_TO_CTX or SCALAR_VALUE

转换后，如果参数是PTR_TO_CTX（指向bpf_context），标志regs为0 。否则如果是SCALAR_VALUE，标记reg为unknown。

否则，直接标记r1的类型为PTR_TO_CTX，且标0 。然后检测参数类型。

调用 do_check(env);

函数主要目的：

当遇见BPF_ALU、BPF_ALU64的指令。对多种可能的ALU操作，比如neg、add、xor、rsh等进行可能的合法性校验（源、目的操作数、寄存器等）。过度细节的校验就不贴上来了。

检验完之后调用 adjust_reg_min_max_vals(env, insn) 计算新的min/max范围与var_off

如果是class==BPF_LDX。即加载指令。

a. 先调用 check_reg_arg(env, insn->src_reg, SRC_OP) 检测src_reg是否可读。

b. 再调用 check_reg_arg(env, insn->dst_reg, DST_OP_NO_MARK) 检测dst_reg是否可写。

c. 调用 check_mem_access(env, env->insn_idx, insn->src_reg,insn->off, BPF_SIZE(insn->code),BPF_READ, insn->dst_reg, false); 检测真正要读取的位置：src_reg + off 是否可读。

除了BPF_LDX以外。本函数还对其他的类型的指令进行了对应的检查。在每个子检查中都是使用的：

check_reg_arg check_mem_access 等进行组合检查。

这个函数是check中用来检查内存访问非常重要的一个函数。

我们主要看一个典型的，当reg是一个指向栈的指针时的情况。

首先我们通过 check_stack_access 检测栈的可访问状况。

接下来通过func函数查找当前的调用栈。

然后通过 update_stack_depth 对每个函数的栈消耗进行维护。如果当前访问的地址超出当前函数的栈范围，那么对当前函数进行栈扩充。

接下来判断读or写操作。

写操作，调用 check_stack_write 检测栈的可写性。

读操作，检测可读性，这里就不展开了，比可写性简单一些。

我们重新回到上层的 bpf_check 中。

函数目的：

本函数也很长，不过相对好理解，我们挑一部分关键的来说。

函数目的：

首先，本函数对指令做了patch，修复一些不合法的指令。处理尾调用等。

fixup_call_args 调用了 jit_subprogs

函数主要目的：

扫描prog，找到bpf2bpf函数调用，找到对应的subprog，存储。

为每个要jit的subprog申请空间。

bpf_int_jit_compile 每个subprog

修正bpf2bpf调用的函数距离（bpf_int_jit_compile）

这里实际上对于函数地址的修正经过了多轮jit，这里看了别的大佬的一种解释。

由于第一次不完全修正函数距离时

函数流程：

这是最主要的jit函数。

内核中实际上有两条可以到达这里的有效jit路径：

第一条是jit_subprogs（这里涉及到bpf2bpf函数调用等，所以是多函数的bpf jit路径）。

另一条是通过bpf_prog_select_runtime，即当bpf_check结束后，调用bpf_prog_select_runtime。

调用： static int do_jit(struct bpf_prog *bpf_prog, int *addrs, u8 *image,int oldproglen, struct jit_context *ctx)

1.首先通过 emit_prologue 构建栈初始化环境。为了符合x64的abi，主要涉及rsp，rbp的操作等。

2.针对类似的普通指令，可以一对一的进行翻译，opcode、eBPF、寄存器相匹配：

3.修正BPF_CALL，当前的imm32 = func_addr-__bpf_call_base

最后调用：

计算出真正的bpf2bpf的调用地址。

4.如果是exit指令，那么按照x64的方式回复栈空间。leave销毁局部栈

5.如果涉及到尾调用的情况：

当imm修正好，深度允许时（小于MAX_TAIL_CALL_CNT），可以直接跳转到callee上（ip+adj_off）

否则，可以通过emit_bpf_tail_call_indirect ，通过indirect的一些检查后，可以实现goto *(prog->bpf_func + prologue_size); ，进而jmp到另外的bpf prog上。

6.最终在 prog->bpf_func 存放编译后的可执行代码。

unsigned int (*bpf_func)(const void *ctx, const struct bpf_insn *insn);

而在jit阶段很多指令都是基于EMIT来做转换的。

举个例子。

在EMIT_mov中首先校验了DST不等于SRC。之后调用了：

在add_2mod中，根据DST，SRC的的值对于byte（指令字节码）做了编码修正。返回修正后的指令编码。

在add_2reg中基于如下的寄存器映射表继续编码修正传递的byte指令。

当 EMIT3 的三条指令编码全部修正完毕后，EMIT((b1) + ((b2) << 8) + ((b3) << 16), 3) 通过位移操作将三条指令整合起来作为参数。

最终调用 emit_code(prog, bytes, len); 直接将对应编码写入对应prog的内存中。

1.首先申请addrs数组用来存储BPF指令翻译后的x64指令地址

2.对一个函数进行多轮pass，每轮pass都做jit，这是因为我们一开始jit的时候，很多后面的指令都没有生成，从而导致jmp跳转无法捕捉到最准确的距离，只能是按照上一步，先预留64bytes（偏大）。第一轮pass过后，addr中会储存每一条指令的偏移地址，但是由于jmp指令不准确，所以此时的地址不是完全正确的，指令长度（jmp）可能也有问题，而通过多轮pass来jit，指令长度不断收敛，直到 (proglen == oldproglen) 才得到准确的位置信息

3.当正确收敛之后，我们会分配空间保存再过最后一轮pass收敛后的jit结果。至此，jit完成。

https://blog.csdn.net/m0_37921080/article/details/82530191

https://blog.csdn.net/liukuan73/article/details/102705963

https://www.cnblogs.com/LittleHann/p/4134939.html

https://www.cnblogs.com/bsauce/p/11583304.html

https://blog.csdn.net/s2603898260/article/details/79371024

https://blog.csdn.net/hjkfcz/article/details/104916719

[招生]科锐逆向工程师培训(2024年11月15日实地，远程教学同时开班, 第51期)