Memory Safe Context Switching

The article delves into how Fil-C achieves memory safety for C's context-switching primitives: setjmp/longjmp and the ucontext APIs. These functions, while powerful for exception handling and coroutines, are highly prone to misuse in traditional C (dubbed "Yolo-C"), often leading to stack corruption and hard-to-debug crashes. Fil-C aims to eliminate these vulnerabilities.

Making setjmp/longjmp Memory Safe

• The "Returns Twice" Enigma: The core issue with setjmp is its ability to return twice, complicating compiler optimizations regarding variable storage (registers vs. stack spill slots). Compilers typically apply special handling for setjmp to prevent incorrect reuse of memory. However, obfuscating setjmp calls can bypass these safeguards, leading to undefined behavior or crashes.
• Fil-C's Safeguards: Fil-C implements several mechanisms:
  • jmp_buf becomes an opaque pointer to a runtime-managed zjmp_buf object, preventing direct manipulation.
  • Compiler-level recognition of setjmp is enforced to ensure optimizations are correctly inhibited.
  • zjmp_buf objects are associated with stack frames, allowing validation that longjmp targets a valid, active frame. This prevents jumps to deallocated or overwritten stacks.
  • The runtime saves and restores internal state, including Garbage Collector (GC) roots, ensuring GC correctness across context switches. Acknowledged as a complex area, potential bugs here would manifest as incorrect GC root restoration.

Making ucontext Memory Safe

• The ucontext APIs: getcontext, setcontext, makecontext, and swapcontext are used for more structured context switching, particularly for implementing fibers and coroutines. They allow creation of new execution contexts with their own stacks.
• Fil-C's Safety Laws for ucontext:
  • ucontext_t objects contain an opaque zfiber_context managed by the runtime, disallowing direct user access to internal state.
  • Fil-C ignores the user-provided stack pointer (ss_sp), allocating its own internal stack for zfiber_context based on ss_size, with added padding for stack overflow detection.
  • A strict state machine for zfiber_context objects prevents illegal transitions (e.g., switching to an uninitialized context or attempting longjmp-like behavior).
  • Thread affinity ensures a zfiber_context cannot be used across different threads, preventing cross-thread stack corruption.
• GC Integration Challenges: Integrating ucontext with Fil-C's on-the-fly garbage collector posed challenges, particularly concerning "grey fibers"—fibers whose stacks might change state (runnable to running and back) during a GC marking phase. Fil-C's solution involves tracking these grey fibers and re-scanning their stacks as needed to prevent objects from being missed by the GC. This is also identified as a highly intricate area where bugs could lurk.

Conclusion: Fil-C successfully provides memory-safe implementations of longjmp/setjmp and ucontext, supporting even these "depraved features" of C. While setjmp/longjmp support is robust, ucontext support is newer and still undergoing testing.