LWN：BPF 指令集架构标准化！

关注了就能看到更多这么棒的文章哦～

Standardizing the BPF ISA

By Daroc Alden
May 30, 2024
LSFMM+BPF
Gemini-1.5-flash translation
https://lwn.net/Articles/975830/

BPF 最出名的是它在 Linux 内核中的应用，但实际上，人们正在努力将 BPF 标准化，使其可以在其他系统上使用。这些系统包括 Windows 上的 eBPF (eBPF for Windows)，以及 uBPF、rBPF、hBPF、bpftime 等。一些硬件制造商甚至正在考虑将 BPF 直接集成到网络硬件中。Dave Thaler 在 2024 年的 Linux 存储、文件系统、内存管理和 BPF 峰会 (Linux Storage, Filesystem, Memory Management, and BPF Summit) 上主持了两个关于跨平台使用不可避免地带来的各种问题以及标准化工作的现状的会议。

Thaler 在峰会的第一天开场时讨论了现在能够运行 BPF 的许多平台。由于有多个编译器和运行时，不可避免地会出现兼容性问题。他将 正在进行的 IETF BPF 标准化工作 (ongoing IETF BPF standardization work) 的目标定义为确保任何编译器都可以与任何符合标准的运行时一起使用。然后，他更详细地解释了在这种特定情况下“符合标准”的含义，这需要首先解释一下标准化文档结构的一些背景知识。

在后来的会议上，Thaler 将更详细地介绍工作组第一个 IETF 草案的具体状态；在最初的会议上，他只是说工作组已经制作了 一个 BPF 指令集架构 (instruction set architecture) 草案 (a draft instruction set architecture)（ISA）规范。该草案定义了所有 BPF 指令的语义。一个问题是，不同的实现可能并不关心是否真正实现每个 BPF 指令。例如，BPF 最初使用了一些指令，这些指令专门针对其作为数据包过滤语言的初始用例；这些数据包过滤指令可能对在其他上下文中运行的 BPF 代码实际上并不有用。

该 ISA 草案将定义的指令分成几组“一致性组(conformance groups)”。因此，一个符合标准的运行时是正确实现了其声称支持的所有一致性组的指定指令的运行时。Thaler 解释说，以这种方式将事物分开有助于运行时（和编译器）准确地传达它们支持的内容。

该 ISA 草案将现有指令分成几组，主要模仿 RISC-V ISA：atomic32、atomic64、base32、base64、divmul32、divmul64 和 packet。其中一些组包含其他组——例如，任何声称实现 base64 的实现也必须实现 base32。事实上，所有 64 位组都包含其 32 位对应组。将来添加到 BPF 的任何新指令都将添加到一个新的一致性组中，因此现有组将永远不会被修改。这意味着一旦一个实现变得符合标准，它就不需要随着 BPF 的新变化而保持最新；它可以继续声称与旧指令组兼容，这样就不用改了。

Thaler 还描述了工作组已确定用于指令弃用的流程。如果一组指令需要因任何原因而被弃用，它们将被添加到一个单独的一致性组中，然后新的实现可以明确地 排除 该组，并且仍然被视为符合标准。处理 BPF 程序的编译器需要接收目标实现的一组一致性组（通过编译器标志或其他配置），并注意只生成支持的指令。base32 组必须由所有实现支持，并且已经相当广泛，因此代码生成不应该是一个大问题。希望最终结果对用户来说将是无缝兼容性。

然而，指令并不是 BPF 的唯一组成部分。另一个需要标准化的领域是平台特定的应用程序二进制接口 (psABI)，它包括一些细节，例如跨越调用保存哪些寄存器、哪个寄存器包含帧指针、堆栈有多大以及其他细节，Thaler 说。所有这一切都还处于不确定的状态，因为工作组尚未制定 psABI 规范的草案。他还提出，可能最终会有多个 psABI，在这种情况下，编译器需要要么选择一个来支持，要么允许某种方式来指定将用于代码生成的 psABI。

José Marchesi 反对将帧指针视为一种应该由 psABI 决定的方案——BPF 使用自动堆栈分配，这意味着运行时在 BPF 寄存器 r10 中管理帧指针。Thaler 回答说，ISA 并没有真正说明这一点；未写的 psABI 需要说明这一点。Marchesi 对此解释并不满意，因为 r10 与其他寄存器不同。特别是，它是只读的。对此点还有一些额外的讨论，但其他观众似乎不同意 Marchesi 的观点，即 r10 的行为应该在 ISA 中指定。

此时，Thaler 转向了另一个与 BPF 兼容性相关的议题：验证器 (verifier)。目前已经存在多个 BPF 验证器，最值得注意的是 Linux 内核中的验证器和 PREVAIL 验证器。一个希望生成可移植 BPF 代码的编译器需要一个关于哪些代码可验证或不可验证的实际描述。这是工作组一直在考虑的事情，但尚未草拟任何关于此方面的规范。

标准现状

在峰会最后一天的第二个环节中，Thaler 向大家更新了 ISA 标准的现状。他首先解释了工作组的任务：为几个特定主题制作一系列标准和信息文档。工作组如何做这些事是由他们决定的——因此他们可以并行处理这些文档，但总体上一直在按照优先级顺序进行。

由于拥有 ISA 是能够讨论其他主题（如 psABI 和验证器要求）的基础，因此 ISA 是工作组首先关注的文档。在该环节进行时，ISA 已经“接近完成”，最后的意见征集将在第二天结束。截至本文撰写之时，ISA 已列入 6 月 13 日会议 的议程，该会议由互联网工程指导组 (IESG) 举办。

对于不熟悉 IETF 细节的人来说，这可能无法提供关于文档实际状态的清晰全貌；Thaler 简要概述了剩余流程，因为它适用于 BPF ISA。在 6 月 13 日的会议上，IESG 将对拟议的文档进行投票。如果未能通过，任何问题或意见将反馈给工作组，文档将被修改，然后在稍后日期提交给 IESG。如果投票通过，该文档将进入 RFC 编辑的队列。RFC 编辑将文档转换为 RFC 的特定格式，更新所有引用，并为其分配一个暂定的 RFC 号码。然后，作者将有机会在文档发布之前审查 RFC 编辑的更改，分配的号码将成为最终号码。

同时，该文档还需要经互联网号码分配机构 (IANA) 审查，因为 IANA 将负责管理官方一致性组列表。Thaler 将 IANA 描述为由“流程人员”组成，只要为注册新的符合性组描述的过程没有问题，他们不太可能对文档提出任何异议。

所有这些流程都相当快，除了等待 IESG，IESG 每两周才开会一次。因此，他说，BPF ISA 很可能在 6 月底成为正式的 RFC。工作组主席 David Vernet 询问 Thaler 是否有什么事情是与会 BPF 开发人员可以做的，从而能避免延误。Thaler 说没有，因为一切都取决于 IETF——除了快速回复反馈。

特别是，Thaler 在最后的意见征集期间已经收到了一些反馈。由于意见征集期定于第二天结束，他认为，如果与会者能快速回复这些问题，那么可能就不会有任何其他延误。他浏览了反馈，其中大部分都很小，而且已经纳入了。然而，有一条反馈引发了实际讨论。Eric Klein 建议 ISA 不应该定义 BPF 程序可用的寄存器范围，说这应该移到 (尚未编写的) psABI 中。这个建议并没有得到很好的认可。

包括 Marchesi 在内的几位听众发言说，CPU 拥有的寄存器数量应该始终是 ISA 的一部分。一位听众问，在不知道有多少寄存器的情况下，编译器如何为平台生成代码。Marchesi 和 Alexei Starovoitov 分别提到，寄存器使用方式的一些细节，例如使用 r0 表示返回值，或使用帧指针，并不一定需要包含在 ISA 中，但他们仍然认为包含有效的寄存器数量很重要。Thaler 记录了所有人的回应，并打算将寄存器数量 (目前为 11 个——10 个通用寄存器和 1 个只读帧指针) 保留在 ISA 中。

然后 Vernet 询问他们为什么要将寄存器数量标准化为 11 个——除了与现有 BPF 实现的行为相匹配以外。另一位听众说，这是一个“非常好的问题，但它不应该影响标准”，因为这是所有现有的可移植 BPF 程序所做的。Marchesi 建议 ISA 可以说指令编码为最多 16 个寄存器留出了空间，但具体数量取决于实现，最小值为 11 个。其他几个人力推用 11 个寄存器继续进行，指出如果这是一个真正的问题，那么它会在 ISA 最后的意见征集的最后 48 小时之前出现。

一旦 ISA 被标准化，下一步 (虽然他明确表示这只是一个粗略的顺序) 将是描述 BPF 验证器期望的信息标准。这可能包括确保属性，例如不使用未定义的指令、不取消引用无效指针，或确保程序终止。Marchesi 指出，如果该文档以编号或命名的规则列表的形式出现，那么编译器错误消息 (以及内部代码) 可以通过名称引用它们，这对编译器来说会很方便。Starovoitov 认为，这些类型的要求应该放在单独的文档中；Thaler 同意，指出编译器期望文档在他的列表中排在后面。工作组即将完成的其他任务包括标准化 BPF 类型格式 (BTF)，以及关于生成可移植二进制文件的说明性文档——包括记录可验证代码的编译器期望以及 psABI。

Thaler 谈了一下他比较喜欢的 psABI 工作形式，然后转向最后议题，需要听众帮助的一点：BPF 的 ELF 配置文件。他有一个 草案提案，但他不确定应该如何正确标准化。ELF 不是 IETF 标准——它是作为 System V 规范 的一部分定义的。因此，他问道，注册 BPF 特定 ELF 信息 (例如 ELF 头文件中的 BPF CPU 标识符) 的正确方法是什么？

听众的共识是，System V 已经 基本过时，向 System V 邮件列表发送一封邮件，声称 BPF CPU ID 应该就足够了。至此，该环节结束。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～