在当今操作系统内核扩展领域，eBPF 已成为事实标准，但其依赖的内核验证器（verifier）带来了严重的语言 - 验证器鸿沟（language-verifier gap）。开发者编写符合语言安全契约的代码，却可能因验证器的内部限制、实现缺陷或与编译器的不一致而被拒绝。Rex 框架应运而生，它通过直接依赖 Rust 语言的安全特性，结合轻量级运行时检查，为内核扩展提供了一种全新的并发安全验证范式。
语言基础安全：从验证器依赖到类型系统保证
Rex 的核心设计理念是关闭语言 - 验证器鸿沟。与 eBPF 不同，Rex 不依赖独立的内核验证器进行静态分析，而是将安全保证建立在 Rust 语言本身的安全特性之上。Rex 扩展程序必须严格使用 Rust 的安全子集编写，禁止任何unsafe代码，同时排除那些可能干扰对象生命周期管理的语言特性，如core::mem::forget和ManuallyDrop。
这种设计的关键优势在于，Rust 的类型系统 —— 特别是所有权（ownership）和借用检查器（borrow checker）—— 在编译时就能保证内存安全和数据竞争自由。在多核环境中，当多个执行线程可能同时访问共享数据时，Rust 的借用规则确保要么有多个不可变引用，要么只有一个可变引用，这从根本上消除了数据竞争的可能性。
正如 Rex 论文所述：“Rex builds upon language-based safety to provide safety properties desired by kernel extensions, along with a lightweight extralingual runtime for properties that are unsuitable for static analysis.” 这种分层方法将适合静态分析的属性交给编译器，将需要运行时检查的属性交给轻量级运行时。
内存安全与类型安全的双重保障
Rex 在内存安全方面采用了两种策略，分别针对扩展程序拥有的内存和内核拥有的内存。对于扩展程序拥有的内存（如栈缓冲区），Rex 利用 Rust 的泛型编程特性，通过类型参数在编译时确定内存大小，确保传递给内核辅助函数的大小始终匹配类型定义。对于内核拥有的内存（如映射值指针和数据包指针），Rex 将其抽象为 Rust 的切片（slice），提供运行时边界检查。
在类型安全方面，Rex 扩展了 Rust 的类型系统以支持安全的类型转换（transmute）。Rex 定义了一组基本标量类型作为安全转换目标，要求转换目标类型必须是这些安全类型之一，或者是所有成员都是安全类型的结构体。这种设计确保了类型转换不会引入安全漏洞，同时保持了编程的灵活性。
运行时安全机制：栈、终止与异常处理
虽然 Rust 的类型系统提供了强大的静态安全保证，但某些安全属性难以通过静态分析完全验证。为此，Rex 实现了一套轻量级运行时机制，涵盖栈安全、程序终止和异常处理三个关键领域。
栈安全：静态与动态结合的混合方法
内核栈空间有限（x86-64 上为 4 页），栈溢出可能导致内核崩溃。Rex 采用混合方法确保栈安全：对于没有间接或递归调用的扩展程序，通过编译器遍历全局静态调用图计算总栈使用量；对于包含间接或递归调用的程序，则在每个函数调用前插入运行时检查。
Rex 为每个扩展程序分配专用的每 CPU 内核栈（8 页），在执行扩展前，调度器保存当前上下文栈指针，切换到专用栈。栈使用阈值设为 4 页，为内核辅助函数和异常处理预留足够空间。这种设计比 eBPF 的栈安全机制更强大，因为 eBPF 的静态分析难以处理间接尾调用和不可控的程序嵌套。
程序终止：硬件定时器看门狗
无限循环可能使内核挂起，因此终止保证对内核扩展至关重要。Rex 利用 Linux 的高分辨率定时器（hrtimer）子系统实现看门狗机制。每个 CPU 设置一个定时器，周期性触发并检查扩展程序的运行时间是否超过阈值（默认设置为 RCU CPU 停滞超时时间）。
当定时器触发时，如果扩展程序超时且处于可中断状态（执行扩展代码而非内核辅助函数或异常处理程序），定时器处理程序将保存的指令指针寄存器覆盖为异常处理程序地址。从定时器中断返回后，扩展程序执行异常处理逻辑，安全清理资源并优雅退出。
安全异常处理：崩溃停止模型
Rust 的异常（panic）处理在用户空间使用 Itanium 异常处理 ABI，但这不适合内核扩展环境。Rex 实现了自己的异常处理框架，包含优雅退出和资源清理两个组件。
当扩展程序触发 panic 时，Rex 的 panic 处理程序释放当前分配的内核资源，然后将控制流转到内核中的着陆垫（landingpad），打印调试信息到内核环缓冲区并返回默认错误码。着陆垫将控制流重定向到调度器中的预定义标签，恢复旧的栈指针值，有效展开栈并重置上下文。
资源清理的关键洞察是：扩展程序只能通过显式调用辅助函数获取内核资源。因此，Rex 在执行期间在每 CPU 缓冲区中记录分配的内核资源，在 panic 时遍历缓冲区并正确释放资源。Rex 采用崩溃停止（crash-stop）故障模型 —— 发生 panic 的扩展程序从内核中移除，任何使用的映射和共享这些映射的其他 Rex 扩展也会递归移除。
RAII 资源管理与数据竞争预防
资源管理是并发安全的重要组成部分。Rex 使用 Rust 的资源获取即初始化（RAII）模式管理内核资源。对于扩展程序可能获取的每个内核资源（如自旋锁），Rex 内核 crate 定义了一个 RAII 包装器类型，将资源生命周期与包装器对象绑定。
例如，当程序从内核获取自旋锁时，Rex 内核 crate 构造并返回一个锁保护（lock guard）。锁保护通过 Rust 的Drop trait 实现 RAII 语义，其 drop 处理程序释放锁。编译器在对象生命周期结束时插入 drop 调用，Rex 实现自己的资源清理机制处理异常情况。
这种设计自动管理内核资源，确保安全获取和释放，扩展程序无需显式释放锁或删除锁保护。对于死锁预防，Rex 遵循 eBPF 的解决方案：程序一次只能持有一个锁，通过每 CPU 变量跟踪当前是否持有锁 —— 尝试获取第二个锁的程序将触发 Rust panic。
并发安全验证的工程实践意义
Rex 的并发安全验证方法对内核扩展开发具有重要实践意义。首先，它消除了 eBPF 开发中常见的验证器规避模式，如将大型程序拆分为多个小程序、提示 LLVM 生成验证器友好代码、修改代码以辅助验证等。开发者可以专注于业务逻辑，无需理解验证器的内部实现细节。
其次，Rex 提供了更可预测的开发体验。由于安全属性在语言层面定义和执行，编译器错误信息直接映射到源代码，而不是像 eBPF 验证器日志那样在字节码层面提供难以理解的反馈。这显著降低了调试和维护成本。
第三，Rex 支持更复杂的扩展程序。没有程序大小和复杂性的限制，开发者可以编写更自然、更模块化的代码，无需为了满足验证器约束而做出设计妥协。这在实现如 BPF Memcached Cache（BMC）等复杂扩展时尤为明显，Rex 版本比 eBPF 版本代码更简洁、逻辑更清晰。
限制与权衡
Rex 设计也存在权衡。为了关闭语言 - 验证器鸿沟，Rex 要求内核扩展使用 Rust 编写，虽然其设计原则适用于其他安全语言。Rex 将 Rust 工具链纳入可信计算基（TCB），增加了额外的运行时复杂性。此外，Rex 目前不支持动态内存分配，且无法中断已经在硬中断或不可屏蔽中断中执行的扩展程序。
值得注意的是，Rex 扩展和 eBPF 扩展可以共存 —— 它们代表了不同的权衡。Rex 针对大型、复杂的内核扩展，其中可用性和可维护性至关重要；eBPF 更适合小型、简单的扩展，特别是那些需要在硬中断上下文中执行的程序。
结论
Rex 框架通过将并发安全验证从独立的内核验证器转移到语言类型系统和轻量级运行时，为内核扩展开发提供了新的范式。Rust 的所有权模型和借用检查器在编译时保证内存安全和数据竞争自由，而运行时机制处理栈安全、程序终止和异常处理等难以静态验证的属性。
这种方法不仅关闭了语言 - 验证器鸿沟，提高了开发体验和代码可维护性，而且在实际性能测试中与 eBPF 表现相当。对于需要在多核环境中实现复杂逻辑的内核扩展开发者，Rex 提供了一种更自然、更可靠的并发安全验证方案，代表了内核扩展技术的重要演进方向。
随着 Rust 在 Linux 内核中的采用日益成熟，以及更多开发者熟悉基于类型系统的安全编程范式，Rex 所代表的语言基础安全方法有望成为未来内核扩展开发的主流模式，为操作系统内核的可扩展性和安全性提供更坚实的基础。
资料来源：
- arXiv 论文：Rex: Safe and usable kernel extensions in Rust
- GitHub 仓库：rex-rs/rex