eBPF -- extended Berkeley Packet Filter 是一种能在内核中抓包的机制。（嗯，感觉自己都不认可这句话。）
整体架构
从架构上来看大概是这个样子的。
Kernel
+--------------------------------+
| |
| ............. |
| . Map . * * * * |
| ............. BPF |
| ^ * * |
| | |
+------------+ bpf() | v * * |
| Userspace | syscall | +----------------+ Prog |
| |< - - - - >| | bpf_map::ops |< - >* * |
| Process | | | (bpf/helpers.c)| |
| (libbpf.a) | | +----------------+ * * * * |
+------------+ | |
+--------------------------------+
在内核中有两部分：
整个机制的运行过程为：
用户态将prog(包含了map定义)注入到内核中，用户态和内核态(prog)通过各自的api来访问、修改map数据。最终用户态将相关信息打印获得输出。
例子及使用
有效学习的途径之一就是通过例子，而在内核源码中就有很多eBPF的例子代码供我们学习。他们在samples/bpf目录下。
编译
虽然找到了例子，但是要跑起来还要再花些功夫。在ebpf例子的编译上和普通的程序编译略有不同。
首先，为了能使ebpf发挥效能，还需要内核这边的一些配置。比如我在网上找到的这么些内核配置的要求。
CONFIG_BPF=y
CONFIG_BPF_SYSCALL=y
# [optional, for tc filters]
CONFIG_NET_CLS_BPF=m
# [optional, for tc actions]
CONFIG_NET_ACT_BPF=m
CONFIG_BPF_JIT=y
# [for Linux kernel versions 4.1 through 4.6]
CONFIG_HAVE_BPF_JIT=y
# [for Linux kernel versions 4.7 and later]
CONFIG_HAVE_EBPF_JIT=y
# [optional, for kprobes]
CONFIG_BPF_EVENTS=y
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_ACT_POLICE=m
CONFIG_NET_ACT_GACT=m
CONFIG_DUMMY=m
CONFIG_VXLAN=m
除此之外，执行make之前还要安装两个编译工具， clang/llvm。因为当前的gcc不支持生成eBPF的字节码。
在Fedora上运行以下命令安装 clang/llvm。
yum install clang llvm
好了，准备好了一切，我们就可以编译ebpf的例子了。
每一个可执行文件都可以拿来做实验。
示例 -- sockex1
此时我们挑一个看着比较简单的例子来学习以下，sockex1这个例子看上去代码比较少，那就挑这个吧。
这个例子有两个文件组成： sockex1_user.c sockex1_kern.c。后者看上去短，那就先看kern.c。
struct {
__uint(type, BPF_MAP_TYPE_ARRAY);
__type(key, u32);
__type(value, long);
__uint(max_entries, 256);
} my_map SEC(".maps");
SEC("socket1")
int bpf_prog1(struct __sk_buff *skb)
{
int index = load_byte(skb, ETH_HLEN + offsetof(struct iphdr, protocol));
long *value;
if (skb->pkt_type != PACKET_OUTGOING)
return 0;
value = bpf_map_lookup_elem(&my_map, &index);
if (value)
__sync_fetch_and_add(value, skb->len);
return 0;
}
如之前整体架构中所述，eBPF由两部分组成： 作为数据的map, 作为代码的prog。我们这个例子中数据和代码各一份。
虽然有很多函数看不懂，但是大致的意思就是在my_map中做了某个查找，符合条件时增加skb->len。那我们再来看看用户态都做了些什么。
int main(int ac, char **argv)
{
[...]
snprintf(filename, sizeof(filename), "%s_kern.o", argv[0]);
if (bpf_prog_load(filename, BPF_PROG_TYPE_SOCKET_FILTER,
&obj, &prog_fd))
return 1;
map_fd = bpf_object__find_map_fd_by_name(obj, "my_map");
sock = open_raw_sock("lo");
assert(setsockopt(sock, SOL_SOCKET, SO_ATTACH_BPF, &prog_fd,
sizeof(prog_fd)) == 0);
f = popen("ping -4 -c5 localhost", "r");
(void) f;
for (i = 0; i < 5; i++) {
long long tcp_cnt, udp_cnt, icmp_cnt;
int key;
key = IPPROTO_TCP;
assert(bpf_map_lookup_elem(map_fd, &key, &tcp_cnt) == 0);
key = IPPROTO_UDP;
assert(bpf_map_lookup_elem(map_fd, &key, &udp_cnt) == 0);
key = IPPROTO_ICMP;
assert(bpf_map_lookup_elem(map_fd, &key, &icmp_cnt) == 0);
printf("TCP %lld UDP %lld ICMP %lld bytes\n",
tcp_cnt, udp_cnt, icmp_cnt);
sleep(1);
}
return 0;
}
其中大致的流程为：
打开了loop的socket，并且和加载的prog做了关联
看着好像不难，但是依然一头雾水。不着急，我们一点点来。
里应外合
从架构和上面的例子中看出，eBPF包含两部分，内核态的prog和用户态的程序。两者之间如何通信则成了我心中的一块疑团。
好在踏(误)破(打)铁(误)鞋(撞)， 也算是找到了些端倪。
内核中的bpf helper
在插入内核的prog中，我们可以看到这样的函数
bpf_map_lookup_elem()
这个就是在操作map数据。因为这段代码需要在内核中调用，那么在内核中这个函数又在哪里呢？对了，这个东西就叫BPF_CALL。
BPF_CALL_2(bpf_map_lookup_elem, struct bpf_map *, map, void *, key)
{
WARN_ON_ONCE(!rcu_read_lock_held());
return (unsigned long) map->ops->map_lookup_elem(map, key);
}
怎么样，感觉也还行吧。
用户态的libbpf
内核态的函数在内核中直接定义了，还比较好找。但是在用户态的程序又如何和内核中的map打交道？
这个东西叫 libbpf， 在内核源码中tools/lib/bpf目录下。当我们仔细看samples/bpf目录下的Makefile，我们可以看到用户态程序在链接时使用了这个库。
# Libbpf dependencies
LIBBPF = $(TOOLS_PATH)/lib/bpf/libbpf.a
TPROGS_LDLIBS += $(LIBBPF) -lelf -lz
# Link an executable based on list of .o files, all plain c
# tprog-cmulti -> executable
quiet_cmd_tprog-cmulti = LD $@
cmd_tprog-cmulti = $(CC) $(tprogc_flags) $(TPROGS_LDFLAGS) -o $@ \
$(addprefix $(obj)/,$($(@F)-objs)) \
$(TPROGS_LDLIBS) $(TPROGLDLIBS_$(@F))
$(tprog-cmulti): $(tprog-cobjs) FORCE
$(call if_changed,tprog-cmulti)
$(call multi_depend, $(tprog-cmulti), , -objs)
知道了这点，我们就来看看函数bpf_map_lookup_elem在用户态中它的定义：
bpf_map_lookup_elem()
sys_bpf(BPF_MAP_LOOKUP_ELEM, &attr, sizeof(attr));
syscall(__NR_bpf, cmd, attr, size);
啊，原来如此。用户态是通过bpf这个系统调用来和内核通信的。再回过去看看整体架构中的那个图，是不是又发现了什么？
让我们还是进到bpf系调用看一下：
SYSCALL_DEFINE3(bpf, int, cmd, union bpf_attr __user *, uattr, unsigned int, size)
{
union bpf_attr attr;
int err;
...
switch (cmd) {
case BPF_MAP_CREATE:
err = map_create(&attr);
break;
case BPF_MAP_LOOKUP_ELEM:
err = map_lookup_elem(&attr);
break;
case BPF_MAP_UPDATE_ELEM:
err = map_update_elem(&attr);
break;
case BPF_MAP_DELETE_ELEM:
err = map_delete_elem(&attr);
break;
...
从函数原型和实现上我们可以看到，sys_bpf为了满足不同的需求，按照cmd类型做了分类处理。
比如我们在用户态执行的bpf_prog_load，在这里对应的就是BPF_MAP_CREATE；bpf_map_lookup_elem对应的是BPF_MAP_LOOKUP_ELEM。
沿着这个思路，我们是不是就能找到用户态中如何创建，访问，修改内核中的map数据了呢？Bingo!
Where Where Where?
到这里看似我们已经了解了一切，但是突然有个非常关键的问题冒了出来 -- 添加到内核中的prog究竟什么时候会被触发？
比如在samples/bpf/cpustat_kern.c添加的这么一段prog
SEC("tracepoint/power/cpu_frequency")
int bpf_prog2(struct cpu_args *ctx)
随之而来的有两个问题：
为什么传进来的参数是 struct cpu_args 这样的结构体？
当然现在这个整体的疑惑我还是没有完全打开，不过找到了一把小小的钥匙。这个钥匙还是在对应的用户态程序中。
让我们从用户态samples/bpf/cpustat_user.c中的 load_bpf_file()开始
load_bpf_file(file)
do_load_bpf_file(file, NULL)
load_and_attach()
is_tracepoint = strncmp(event, "tracepoint/", 11) == 0;
if (is_tracepoint) {
strcpy(buf, DEBUGFS);
strcat(buf, "events/");
strcat(buf, event);
strcat(buf, "/id");
}
...
efd = sys_perf_event_open(&attr, -1/*pid*/, 0/*cpu*/, -1/*group_fd*/, 0);
err = ioctl(efd, PERF_EVENT_IOC_ENABLE, 0);
err = ioctl(efd, PERF_EVENT_IOC_SET_BPF, fd);
具体细节还有很多，可以看到的是，SEC的定义影响了prog的加载过程。比如对tracepoint开头的SEC，加载时回去找到debugfs中对应的事件id。并通过后续一系列的操作将这个事件和prog联系起来。
对于tracepoint类型的bpf，当前找到的两个信息是：
内核中通过函数trace_call_bpf()来调用到prog
调用时的参数结构可以在 /sys/kernel/debug/tracing/events/event/format 文件中找到
好了，eBPF的基础学习就到这里。后续的内容已经超出了eBPF本身的范围，而是包括perf event在内的其他内核组件如何和eBPF互动的内容了。
到这里，先到这里。