Bilingual

Memory Safe Context Switching
22 days ago
- Fil-C supports memory-safe context switching via longjmp/setjmp and ucontext APIs, preventing stack corruption.
- setjmp/longjmp are used for exception handling, while ucontext APIs (getcontext, setcontext, makecontext, swapcontext) implement coroutines/fibers.
- Fil-C makes setjmp/longjmp safe by storing jmp_buf as an opaque zjmp_buf, restricting direct calls, and validating stack frame ancestry.
- ucontext safety is achieved using opaque zfiber_context objects, a strict state machine, thread affinity, and GC integration with grey fiber tracking.
- The implementation ensures no misuse leads to dangling stack execution; unsafe operations cause panics or compile-time errors.
- GC integration handles fiber stacks during marking via grey fiber lists to prevent race conditions in on-the-fly garbage collection.
- Fil-C's ucontext support is available in glibc builds (from source after version 0.680), with setjmp/longjmp being more mature.
- Examples demonstrate how volatile variables and compiler optimizations affect setjmp behavior, emphasizing Fil-C's compliance with C semantics.
Introduce a memory safe compilation mode inspired by Fil-C
a day ago
- Introduces a memory-safe compilation mode inspired by Fil-C, which differs from Rust by offering stronger memory safety guarantees without relying on unsafe code or escape hatches.
- Proposes a new ABI named 'fil' to implement Fil-C techniques, including invisicaps and syscall interception, for full memory safety across Zig and C/C++ dependencies.
- Aims to achieve memory safety with a performance penalty of 1-6x, preventing use-after-free and type confusion through unique type IDs and runtime pointer provenance checks.
- Discusses challenges such as intercepting all syscalls and inline assembly, while avoiding language changes by using compiler and standard library modifications.
- Highlights the potential for Zig to become a leading toolchain for memory-safe executables, even with C/C++ dependencies, surpassing Rust's safety in practice.
InvisiCaps: The Fil-C Capability Model
16 hours ago
- Fil-C ensures memory safety via a capability system for pointers, dynamically tracking allowed objects and prohibiting out-of-bounds, use-after-free, and other unsafe accesses.
- InvisiCaps are the latest capability model, replacing PLUT, SideCaps, and MonoCaps, offering 64-bit pointers on 64-bit systems and reduced performance overhead to about 4x.
- InvisiCaps support meaningful union usage, thread safety, and flexible memory type reinterpretation without compromising safety.
- Each flight pointer has a trusted lower bound (for bounds checks) and an untrusted intval (the raw C pointer value); lower is immutable by the program.
- When pointers are stored to heap, the intval goes in the object payload and the lower in a separate aux allocation, keeping capabilities invisible to the program.
- Atomic pointers use atomic boxes for lock-free operations, while non-atomic pointers use a cheaper approach with aux allocations.
- Use-after-free is detected deterministically by setting the upper bound equal to the lower, causing a panic on access.
- The model is fanatically compatible, supporting even undefined behavior idioms, and is inspired by SoftBound and CHERI but with better thread safety and compatibility.

Hasty Briefsbeta

#fil-c

Memory Safe Context Switching

Introduce a memory safe compilation mode inspired by Fil-C

InvisiCaps: The Fil-C Capability Model