前言
本文翻译自 2020 年 Facebook 的一篇博客:BPF Portability and CO-RE[1], 作者 Andrii Nakryiko。
关于 BPF CO-RE 的目标,引用文中的一段总结就是:
由于译者水平有限,本文不免存在遗漏或错误之处。如有疑问,请查阅原文。
以下是译文。
本文介绍 BPF 可移植性面临的问题,以及 BPF CO-RE(Compile Once – Run Everywhere) 是如何解决这些问题的。
(e)BPF 出来之后,社区一直在试图简化 BPF 程序的开发过程 —— 最好能像开发 用户空间应用程序(userspace application)一样简单直接 —— 可惜这个目标从未实现。 具体来说,在使用性(usability)方面确实有很大进步,但另一个重要方面却被忽略了 (大部分出于技术原因):可移植性。
那么,什么是”BPF 可移植性“(BPF portability)?我们定义它是这样一种能力:编写的程序通过编译和内核校验之后,能正确地在不同版本的内核上运行 —— 而无需针对不同内核重新编译。
本文首先介绍 BPF 可移植性面临的问题,然后介绍我们的**解决方案:BPF CO-RE** (Compile Once – Run Everywhere)。接下来内容如下:
BPF 程序是由用户提供的、经过验证之后**在内核上下文中执行**的程序。 BPF运行在内核内存空间(kernel memory space)执行,能访问大量的 内核内部状态(internal kernel state)。 这使得 BPF 程序功能极其强大,也是为什么它能成功地应用在大量不同场景的原因之一。
但另一方面,与强大能力相伴而生的是我们如今面临的可移植性问题:BPF 程序 并不控制它运行时所在内核的内存布局(memory layout)。 因此,BPF 程序只能运行在开发和编译这些程序时所在的内核。
另外,内核类型(kernel types)和数据结构(data structures)也在不断变化。 不同的内核版本中,同一结构体的同一字段所在的位置可能会不同 —— 甚至已经 移到一个新的内部结构体(inner struct)中。此外,字段还可能会被重命名、删除、 改变类型,或者(根据不同内核配置)被条件编译掉。
以上分析可知,内核版本升级时很多东西都会发生变化,而 BPF 开发者希望能够避免这些变化对 BPF 程序造成影响。这听上去似乎不可能 —— 内核环境都在不断变化, 依赖内核环境执行的 BPF 程序又如何能幸免于难呢?
但实际上,这是可能的:
opensnoop
,它基于 kprobes/tracepoints 跟踪进程打开的文件, 因此**只要能拦截到少数几个系统调用**就能工作。由于系统调用接口 提供稳定的 ABI,不会随着内核版本而变,因此这样的 BPF 程序做到可移植是问题不大的。
不幸的是,这种类型的 BPF 程序很少,而且它们能做的事情通常也是非常有限的。struct sk_buff
和 struct __sk_buff
。
很多 BPF 程序类型都有类似的机制,这种封装在 BPF 中称为上下文(context),触发 BPF 程序执行时,一般传递的就是这样的上下文(指针类型,例如 struct __sk_buff *ctx
)。因此,如果开发 BPF 程序时使用的是这些结构体,那这样的程序大概率是可移 植的。struct sk_buff
是内核中的数据包表示,字段非常多,并且经常发生变化;struct __sk_buff
是 BPF 校验器提供的一个 sk_buff 的稳定接口, 或者说一组属性集合。将用户程序与底层的 struct sk_buff
解耦开来, 因此后者内存布局发生变化时,不会影响 BPF 程序。struct __sk_buff
字段的访问都会被透明地转换成对 struct sk_buff
的访问。但是,一旦需要查看原始的内核内部数据(raw internal kernel data)—— 例如 常见的表示进程或线程的 struct task_struct
,这个结构体中有非常详细的进程信息 —— 那你就只能靠自己了。对于 tracing、monitoring 和 profiling 应用来说这个需求 非常常见,而这类 BPF 程序也是极其有用的。
在这种情况下,如何保证读到的一定是我们期望读的那个字段呢 —— 例如,
struct task_struct
offset 8 地址读取数据,这还没完:如果这个字段被改名了呢?例如,thread_struct
的 fs
字段(获取 thread-local storage 用), 在 4.6 到 4.7 内核升级时就被重命名为了 fsbase
。
另一种情况:内核版本相同,但内核编译时的配置不同,导致 结构体的某些字段在编译器时被完全移除了。
具体例子:某些可选的审计字段。
所有这些都意味着:依赖**开发环境本地的内核头文件**编译的 BPF 程序, 是无法直接分发到其他机器运行 —— 然后期待它们返回正确结果的。 这是由于不同版本的内核头文件所假设的内存布局是不同的。
目前,人们可以用 BCC[2] (BPF Compiler Collection) 解决这个问题,使用方式如下:
kernel-devel
包)然后现场执行编译、加载、运行。这种方式能确保 BPF 程序期望的内存布局与目标机器内核的内存布局是完全一致的。
对于那些内核版本相关的可选字段或条件编译相关的配置代码,只需要在源代码中 用 #ifdef
/#else
做处理,BCC 内置的 Clang 能正确处理这些宏,最终剩下的就是与 当前内核相匹配的源代码。这就是 BCC 解决内核版本差异的方式。
BCC 方式可行,但存在一些很大的缺点:
总体来说,虽然 bcc 是一个很伟大的工具 —— 尤其是用于快速原型、实验和开发小工具 —— 但 当用于广泛部署生产 BPF 应用时,它存在非常明显的不足。
为了更彻底地解决 BPF 移植性问题,我们设计了 BPF CO-RE,并相信这是BPF 程序的未来开发方式,尤其适用于开发复杂、真实环境中的 BPF 应用。
BPF CO-RE 将它所依赖的如下软件栈和它的数据集中到了一起,
使得我们能以一种轻松的方式编写可移植 BPF 程序,在单个预编译的 BPF 程序内 (pre-compiled BPF program)处理不同内核之间的差异。
BPF CO-RE 需要下列组件之间的紧密合作:
以上几部分相结合,提供了一种开发可移植 BPF 程序的史无前例的能力:这个开发 过程不仅方便(ease),而且具备很强的适配性(adaptability)和表达能力(expressivity)。 在此之前,实现同样的可移植效果只能通过 BCC 在运行时编译 BPF C 程序,而前面也分析了, BCC 开销非常高。
BTF[4] 是 BPF CO-RE 的核心之一, 它是是一种与 DWARF 类似的调试信息,但
如今,让 Linux 内核在运行时(runtime)一直携带 BTF 信息是可行的, 只需在编译时指定 CONFIG_DEBUG_INFO_BTF=y
。内核的 BTF 除了被内核自身使用, 现在还用于增强 BPF 校验器自身的能力 —— 某些能力甚至超越了一年之前我们的想象力所及(例 如,已经有了直接读取内核内存的能力,不再需要通过 bpf_probe_read()
间接读取了)。
更重要的是,内核已经将这个自描述的权威 BTF 信息(定义结构体的精确内存布局等信息)通过 sysfs 暴露出来,在 /sys/kernel/btf/vmlinux
。 下面的命令将生成一个**与所有内核类型兼容的 C 头文件**(通常称为 "vmlinux.h"):
$ bpftool btf dump file /sys/kernel/btf/vmlinux format c
这里说的”所有“真的是**”所有“**:包括那些并未通过 kernel-devel package 导出的类型!
为了让 BPF 加载器(例如 libbpf)将 BPF 程序适配到目标机器所运行的内核上,Clang 增加了几个新的 built-in。它们的功能是导出(emit)BTF relocations(重定位信息),后者是对 BPF 程序想读取的那些信息的高层描述。
例如,如果想访问 task_struct->pid
,那clang 将做如下记录:这是一个位于结构体 struct task_struct
中、类型为 pid_t
、名为 pid
的字段。
有了这种方式,即使目标内核的 task_struct
结构体中,pid
字段位置已经发生了变 化(例如,由于这个字段前面加了新字段),甚至已经移到了某个内部嵌套的匿名结构体 或 union 中(在 C 语言中这种行为是完全透明的,因此内核开发者这样做时并不会有特别 的顾虑),我们仍然能通过名字和类型信息找到这个字段。这称为field offset relocation(字段偏置重定位)。
除了字段重定位,其他一些字段相关的操作,例如判断field existence( 字段是否存在)或者field size(字段长度)都是支持的。 甚至对 bitfields(比特位字段,在 C 语言中是出了名的”难处理“的类型,C 社区一直在努力让它们变得可重定位) ,我们仍然能基于 BTF 信息来使它们可重定位(relocatable),并且整个过程对 BPF 开 发者透明。
libbpf[6] 作为一个BPF 程序加载器(loader), 处理前面介绍的内核 BTF 和 clang 重定位信息。它
libbpf 知道如何对 BPF 程序进行裁剪,以适配到目标机器的内核上。
最终确保 BPF 程序在这个特定的内核上是能正确工作的。
如果一切顺利,你(作为 BPF 应用开发者)将得到一个针对目标机器”定制化裁剪“的 BPF 程序,就像这个程序是专门针对这个内核编译的一样。但这种工作方式无需将 clang 与 BPF 一起打包部署,也没有在目标机器上运行时编译(runtime)的开销。
内核无需太多改动就能支持 BPF CO-RE,这一点可能令很多人感到惊讶。 由于设计合理,因此对于内核来说,libbpf 处理之后的 BPF 程序,与 其他任何合法的 BPF 程序是一样的 —— 与在这台机器上依赖最新内核头文件编译出的 BPF 程序并无区别。这意味要BPF CO-RE 并不依赖最新的内核功能,因此 应用范围更广,适配速度更快。
某些高级场景可能会需要更新的内核,但这些场景很少。接下来介绍 BPF CO-RE 用户侧机制 时会讨论到这样的场景。
接下来看几个真实世界中 BPF CO-RE 的典型场景,以及它是如何解决面临的一些问题的。 我们将看到,
if
/else
条件判断(而不是 BCC 中的那种条件编译 #ifdef
/#else
)。内核 BTF 信息除了用来做字段重定位之外,还可以用来生成一个大的头文件("vmlinux.h
"), 这个头文件中**包含了所有的内部内核类型,从而避免了依赖系统层面的内核头文件**。
通过 bpftool
获得 vmlinux.h
:
$ bpftool btf dump file /sys/kernel/btf/vmlinux format c > vmlinux.h
有了 vmlinux.h
,就无需再像通常的 BPF 程序那样 #include <linux/sched.h>
、#include <linux/fs.h>
等等头文件, 现在只需要 #include "vmlinux.h"
,**也不用再安装 kernel-devel**了。
vmlinux.h
包含了所有的内核类型:
kernel-devel
暴露的内部类型不幸的是,BPF(以及 DWARF)并不记录 #define
宏,因此某些常用 的宏可能在 vmlinux.h 中是缺失的。但这些没有记录的宏中 ,最常见的一些已经在 bpf_helpers.h[7](libbpf 提供的内核侧”库“)提供了。
最常见和最典型的场景就是从某些内核结构体中读取一个字段。
task_struct->pid
字段假设我们想读取 task_struct
中的 pid
字段。
用 BCC 实现,代码很简单:
pid_t pid = task->pid;
BCC 有强大的代码重写(rewrite)能力,能自动将以上代码**转换成一次 bpf_probe_read() 调用** (但有时重写之后的代码并不能正确,具体取决于表达式的复杂程度)。
libbpf
没有 BCC 的代码重写魔法(code-rewriting magic),但提供了几种其他方式来 实现同样的目的。
libbpf
+ BPF_PROG_TYPE_TRACING
(不可移植)如果使用的是最近新加的 BTF_PROG_TYPE_TRACING
类型 BPF 程序,那校验器已经足够智 能了,能原生地理解和记录 BTF 类型、跟踪指针,直接(安全地)读取内核内存,
pid_t pid = task->pid;
从而避免了调用 bpf_probe_read()
,格式和语法更为自然,而且**无需编译器重写**(rewrite)。 但此时,这段代码还不是可移植的。
BPF_PROG_TYPE_TRACING
+ CO-RE(可移植)要将以上 BPF_PROG_TYPE_TRACING
代码其变成可移植的,只需将待访问字段 task->pid
放到编译器内置的一个名为__builtin_preserve_access_index()
的宏中:
pid_t pid = __builtin_preserve_access_index(({ task->pid; }));
这就是全部工作了:这样的程序在不同内核版本之间是可移植的。
bpf_core_read()
(可移植)如果使用的内核版本还没支持 BPF_PROG_TYPE_TRACING
,就必须显式地使用 bpf_probe_read()
来读取字段。
Non-CO-RE libbpf 方式:
pid_t pid;
bpf_probe_read(&pid, sizeof(pid), &task->pid);
有了 CO-RE+libbpf,我们有两种方式实现这个目的。
第一种,直接将 bpf_probe_read()
替换成 bpf_core_read()
:
pid_t pid;
bpf_core_read(&pid, sizeof(pid), &task->pid);
bpf_core_read()
是一个很简单的宏,直接展开成以下形式:
bpf_probe_read(&pid, sizeof(pid), __builtin_preserve_access_index(&task->pid));
可以看到,第三个参数(&task->pid
)放到了前面已经介绍过的编译器 built-int 中, 这样 clang 就能记录该字段的重定位信息,实现可移植。
第二种方式是使用 BPF_CORE_READ()
宏,我们通过下面的例子来看。
task->mm->exe_file->f_inode->i_ino
字段这个字段表示的是当前进程的可执行文件的 inode。 来看一下访问嵌套层次如此深的结构体字段时,面临哪些问题。
用 BCC 实现的话可能是下面这样:
u64 inode = task->mm->exe_file->f_inode->i_ino;
BCC 会对这个表达式进行重写(rewrite),转换成 4 次 bpf_probe_read()/bpf_core_read() 调用, 并且每个中间指针都需要一个额外的临时变量来存储。
下面是 BPF CO-RE 的方式,仍然很简洁,但无需 BCC 的代码重写(code-rewriting magic):
u64 inode = BPF_CORE_READ(task, mm, exe_file, f_inode, i_ino);
另外一个变种是:
u64 inode;
BPF_CORE_READ_INTO(&inode, task, mm, exe_file, f_inode, i_ino);
bpf_core_read_str()
:可以直接替换 Non-CO-RE 的 bpf_probe_read_str()
。BPF_CORE_READ_STR_INTO()
:与 BPF_CORE_READ_INTO()
类似,但会对最后一个字段执行 bpf_probe_read_str()
。bpf_core_field_exists()
:判断字段是否存在, pid_t pid = bpf_core_field_exists(task->pid) ? BPF_CORE_READ(task, pid) : -1;
bpf_core_field_size()
:判断字段大小,同一字段在不同版本的内核中大小可能会发生变化, u32 comm_sz = bpf_core_field_size(task->comm); /* will set comm_sz to 16 */
BPF_CORE_READ_BITFIELD()
:通过直接内存读取(direct memory read)方式,读取比特位字段BPF_CORE_READ_BITFIELD_PROBED()
:底层会调用 bpf_probe_read()
struct tcp_sock *s = ...;
/* with direct reads */
bool is_cwnd_limited = BPF_CORE_READ_BITFIELD(s, is_cwnd_limited);
/* with bpf_probe_read()-based reads */
u64 is_cwnd_limited;
BPF_CORE_READ_BITFIELD_PROBED(s, is_cwnd_limited, &is_cwnd_limited);
某些情况下,BPF 程序必须处理不同内核版本之间常用内核结构体的非细微差异。例如,
task_struct
的 utime
和 stime
字段,原来单位是 jiffies,现在变成了 nanoseconds,因此 调用方必须自己转换单位。对于这些场景,BPF CO-RE 提供了两种互补的解决方式;
externs
Kconfig 全局变量LINUX_KERNEL_VERSION
,表示当前内核的版本。 BPF 程序能用 extern 关键字声明这些变量。CONFIG_HZ
,表示内核的 HZ 数)。接下来的事情交给 libbpf,它会将这些变量分别匹配到系统中相应的值(都是常量), 并保证这些 extern 变量与全局变量的效果是一样的。
此外,由于这些 extern ”变量“都是常量,因此 BPF 校验器能用它们来做一些高级控制流分析和死代码消除。
下面是个例子,如何用 BPF CO-RE 来提取线程的 CPU user time:
extern u32 LINUX_KERNEL_VERSION __kconfig;
extern u32 CONFIG_HZ __kconfig;
u64 utime_ns;
if (LINUX_KERNEL_VERSION >= KERNEL_VERSION(4, 11, 0))
utime_ns = BPF_CORE_READ(task, utime);
else
/* convert jiffies to nanoseconds */
utime_ns = BPF_CORE_READ(task, utime) * (1000000000UL / CONFIG_HZ);
有些场景中,不同版本的内核中有不兼容的类型,无法用单个通用结构体来为所有内核 编译同一个 BPF 程序。struct flavor 在这种情况下可以派上用场。
下面是一个例子,提取 fs
/fsbase
(前面提到过,字段名字在内核版本升级时改了)来 做一些 thread-local 的数据处理:
/* up-to-date thread_struct definition matching newer kernels */
struct thread_struct {
...
u64 fsbase;
...
};
/* legacy thread_struct definition for <= 4.6 kernels */
struct thread_struct___v46 { /* ___v46 is a "flavor" part */
...
u64 fs;
...
};
extern
int LINUX_KERNEL_VERSION __kconfig;
...
struct thread_struct *thr = ...;
u64 fsbase;
if (LINUX_KERNEL_VERSION > KERNEL_VERSION(4, 6, 0))
fsbase = BPF_CORE_READ((struct thread_struct___v46 *)thr, fs);
else
fsbase = BPF_CORE_READ(thr, fsbase);
在这个例子中,对于 <=4.6
的内核,我们将原来的 thread_struct
定义为了 struct thread_struct___v46
。双下划线及其之后的部分,即 ___v46
,称为这个 struct 的 “flavor”。
flavor 部分会被 libbpf 忽略,这意味着在目标机器上执行字段重定位时,struct thread_struct__v46
匹配的仍然是真正的 struct thread_struct
。
这种方式使得我们能在单个 C 程序内,为同一个内核类型定义不同的(而且是不兼容的) 类型,然后在运行时(runtime)取出最合适的一个,这就是用type cast to a struct flavor来提取字段的方式。
没有 struct flavor 的话,就无法真正实现像上面那样“编译一次”,然后就能在不同内核 上都能运行的 BPF 程序 —— 而只能用#ifdef
来控制源代码,编译成两个独立的 BPF 程序变种,在运行时(runtime)由控制应用根据所在机器的内核版本选择其中某个变种。 所有这些都添加了不必要的复杂性和痛苦。 相比之下,以上 BPF CO-RE 方式虽然不是透明的(上面的代码中也包含了内核 版本相关的逻辑),但允许用熟悉的 C 代码结构解决即便是这样的高级场景的问题。
BPF 程序知道内核版本和配置信息,有时还不足以判断如何 —— 以及以何种方式 —— 从该版本的内核获取数据。 在这些场景中,用户空间控制应用(control application)可能是唯一知道 究竟需要做哪些事情,以及需要启用或禁用哪些特性的主体。 这通常是在用户空间和 BPF 程序之间通过某种形式的配置数据来通信的。
要实现这种目的,一种不依赖 BPF CO-RE 的方式是:将 BPF map 作为一个存储配置 数据的地方。BPF 程序从 map 中提取配置信息,然后基于这些信息改变它的控制流。
但这种方式有几个主要的缺点:
这种(确实复杂的)场景的解决方案:使用只读的全局数据(read-only global data)。 这些数据是在 BPF 程序加载到内核之前,由控制应用设置的。
因此,针对上面那个例子,
下面的 BPF 代码例子展示了这种用法:
/* global read-only variables, set up by control app */
const bool use_fancy_helper;
const u32 fallback_value;
...
u32 value;
if (use_fancy_helper)
value = bpf_fancy_helper(ctx);
else
value = bpf_default_helper(ctx) * fallback_value;
从用户空间方面,通过 BPF skeleton 可以很方便地做这种配置。BPF skeleton 的讨论不在 本文讨论范围内,使用它来简化 BPF 应用的例子,可参考内核源码中的runqslower tool[8]。
BPF CO-RE 的目标是:
这是通过几个 BPF CO-RE 模块的组合实现的:
vmlinux.h
消除了对内核头文件的依赖;要成功地编写、部署和维护可移植 BPF 程序,并不是必须用到所有这些 CO-RE 特性。 只需选择若干,用最简单的方式解决你的问题。
BPF CO-RE 使我们回到了熟悉、自然的工作流程:将 BPF C 源码编译成二进制,然后将 二进制文件分发到目标机器进行部署和运行 —— 无需再随着应用一起分发重量级的编译器库、无需消耗宝贵的运行时资源做运行时编译(runtime compilation),也无需等到运行之前才能捕捉一些细微的编译时错误( compilation errors in runtime)了。
[1]
BPF Portability and CO-RE: https://facebookmicrosites.github.io/bpf/blog/2020/02/19/bpf-portability-and-co-re.html
[2]
BCC: https://github.com/iovisor/bcc/
[3]
libbpf: https://github.com/libbpf/libbpf
[4]
BTF: https://www.kernel.org/doc/html/latest/bpf/btf.html
[5]
BTF 去重算法: https://facebookmicrosites.github.io/bpf/blog/2018/11/14/btf-enhancement.html
[6]
libbpf: https://github.com/libbpf/libbpf
[7]
bpf_helpers.h: https://github.com/libbpf/libbpf/blob/master/src/bpf_helpers.h
[8]
runqslower tool: https://github.com/torvalds/linux/tree/master/tools/bpf/runqslower
[9]
summary: http://vger.kernel.org/bpfconf2019.html#session-2
[10]
slides: http://vger.kernel.org/bpfconf2019_talks/bpf-core.pdf
[11]
BPF: The Status of BTF: http://vger.kernel.org/~acme/bpf/devconf.cz-2020-BPF-The-Status-of-BTF-producers-consumers/#/29
[12]
BTF deduplication algorithm: ttps://facebookmicrosites.github.io/bpf/blog/2018/11/14/btf-enhancement.html
原文链接:https://arthurchiao.art/blog/bpf-portability-and-co-re-zh/