Memory Safe Context Switching (longjmp, setjmp) in Fil-C

背景

在 C 语言生态中，longjmp 和 setjmp 以及 ucontext 系列 API（getcontext, setcontext, makecontext, swapcontext）被广泛用于实现异常处理、协程（coroutines）和纤维（fibers）。例如，Boost 库的 fiber 实现就利用了 ucontext。尽管某些操作系统（如 Darwin）已弃用 ucontext，但它们在 glibc 中仍得到良好支持。

然而，这些 API 的误用极易导致栈损坏（stack corruption）或悬空栈（dangling stack）访问，从而破坏内存安全。传统的 C 编译器（文中戏称为 "Yolo-C"）无法防止此类错误，导致程序崩溃时难以调试，甚至可能被攻击者利用。

Fil-C 自 0.680 版本起，通过从源码构建，支持以完全内存安全的方式实现这些上下文切换 API。这意味着在 Fil-C 中，无论用户如何误用这些 API，都不会导致栈损坏或违反 Fil-C 的能力模型（capability model）。

核心内容

1. 传统实现的危险性与 Fil-C 的防御机制

在传统 C 实现中，setjmp 保存调用时的上下文，以便后续 longjmp 恢复执行。这种“返回两次”的特性极具危险性，因为保存的上下文可能指向不再有效的栈帧或已释放的内存。

• 悬空栈风险：如果在保存上下文后，该函数返回或线程退出，恢复上下文时将尝试在一个已失效的栈上执行。
• ucontext 的误用：
  • 使用 makecontext 创建指向某栈的上下文，随后释放该栈，再使用 swapcontext 或 setcontext 切换至该上下文。在 "Yolo-C" 中这会导致在悬空栈上运行；在 Fil-C 中，这会被视为安全错误并导致程序 panic。
  • 误将当前正在执行的上下文作为 swapcontext 的参数。在 "Yolo-C" 中可能表现为类似 longjmp 的行为或悬空栈执行；在 Fil-C 中，这是明确的安全错误。

Fil-C 的核心策略是：在悬空栈上执行是不可能的。所有此类误用要么在发生 longjmp 或 ucontext 调用时立即 panic，要么由于 Fil-C 对栈的管理方式而被视为合法的执行流程。

2. setjmp/longjmp 的内存安全挑战

setjmp 的实现看似简单，实则深藏陷阱。以 x86_64 musl 实现为例，setjmp 仅保存 callee-save 寄存器、栈指针（RSP）和指令指针（RIP）。它并不保存栈本身的内容。

主要难点在于编译器优化与寄存器分配对变量可见性的影响：

• volatile 的作用：在经典示例中，若变量 x 未被标记为 volatile，编译器可能进行常量折叠（constant folding），导致 printf 输出旧值 42 而非新值 666。标记 volatile 可强制编译器将其视为栈分配，确保值被正确观察。
• 寄存器溢出（Spilling）的复杂性：
  • 即使不使用 volatile，若编译器因寄存器压力将变量溢出到栈（spill slots），情况会变得复杂。
  • 编译器允许分析溢出槽的生命周期并复用它们。关键在于：编译器如何知道保存 x=42 的溢出槽必须存活直到 longjmp 发生，而不被复用导致数据污染？
  • 在 "Yolo-C" 中，即使通过内联汇编（inline assembly）强制溢出到不同槽位，编译器仍可能因优化策略导致 x 的值在恢复上下文后变为 42 或其他垃圾值，而非预期的 666。

3. Fil-C 的实现原理

Fil-C 通过改变对栈和上下文的管理方式来从根本上解决上述问题：

1. 栈管理：Fil-C 对栈的管理方式确保了上下文恢复时的栈帧有效性。
2. 安全性保证：
   • 在 Fil-C 中，上述所有涉及寄存器溢出和优化的示例均能按预期工作，包括使用内联汇编混淆变量值的案例。
   • Fil-C 确保变量在 setjmp 保存和 longjmp 恢复之间的生命周期被正确维护，避免了因编译器优化导致的值不一致。
   • 任何试图在无效栈上恢复上下文的行为都会触发 panic，从而防止静默的数据损坏。

关键要点

• 内存安全保证：Fil-C 0.680+ 版本通过从源码构建，支持以完全内存安全的方式实现 longjmp、setjmp 及 ucontext API。
• 防止栈损坏：Fil-C 确保误用这些 API 不会导致栈损坏或悬空栈访问，所有此类错误要么被阻止，要么导致程序 panic。
• 编译器优化兼容：Fil-C 正确处理了编译器优化（如常量折叠、寄存器溢出）对 setjmp/longjmp 语义的影响，确保变量值在上下文恢复后保持一致，无需依赖 volatile 或内联汇编来规避优化。
• 与传统 C 的区别：传统 C 编译器（"Yolo-C"）无法防止悬空栈执行，且可能因优化导致不可预测的行为；Fil-C 通过严格的栈管理和安全检查消除了这些风险。
• API 支持范围：支持 setjmp、longjmp、getcontext、setcontext、makecontext 和 swapcontext。

意义与影响

Fil-C 对 setjmp/longjmp 和 ucontext API 的内存安全实现，解决了 C 语言长期存在的一个核心安全痛点。这些 API 因其强大的控制流切换能力而被广泛使用，但也因其容易引发未定义行为（UB）和内存安全问题而备受诟病。

通过确保这些操作在内存安全的前提下进行，Fil-C 使得开发者可以在享受 C 语言高性能和灵活性的同时，避免由上下文切换引起的复杂 bug 和安全漏洞。这对于构建高可靠性系统、实现安全的协程库以及处理信号异常处理场景具有重要意义。Fil-C 的做法表明，通过改进底层内存管理和编译器交互，可以在不牺牲性能的前提下，显著增强传统 C 代码的安全性。