Abstract:

Ori Bernstein presents "5e: Memory Corruption Detection for the Rest of Us," detailing his work on 5e, an ARM 32 emulator for Plan 9 that incorporates memory corruption detection similar to tools like Valgrind and AddressSanitizer (ASan). He highlights the pervasive nature of memory bugs in C programs (e.g., out-of-bounds access, uninitialized reads) and contrasts Plan 9's traditional "get good" approach with external solutions. Bernstein's 5e leverages a "shadow map" in its emulation layer, assigning allocated and initialized states to memory bytes to dynamically catch errors. While currently a work in progress with limitations (e.g., stack unwinding, red zones), he proposes a more efficient future direction: integrating this instrumentation directly into the linker, which would provide better performance and more accurate stack handling, albeit at the cost of significantly larger binary sizes.

Exploring "5e": Memory Corruption Detection for C Programs

• 0:28 5e: An ARM Emulator for Debugging: Ori Bernstein introduces "5e," an ARM 32 emulator for Plan 9 (a fork of an existing 5e emulator) designed to detect memory corruption. It runs ARM binaries, handling syscalls and file I/O, as if they were running natively.
• 1:25 The Problem with C: C programs are highly susceptible to memory bugs like segmentation violations, panics, out-of-bounds reads/writes, and accessing uninitialized memory, with the language offering minimal built-in protection.
• 3:15 Valgrind and AddressSanitizer: The presentation contrasts Plan 9's traditional "don't make bugs" approach with modern debugging tools like Valgrind (a binary emulator that checks memory accesses) and AddressSanitizer (ASan, a compiler-based instrumentation tool).
• 5:32 5e's Shadow Map Implementation: 5e combines emulation with a "shadow map" concept. This map, separate from the program's address space, tracks the allocated and initialized state (using two bits per four bytes of memory) for every byte in the program's memory segments (text, data, BSS, stack).
• 7:00 Dynamic Bug Detection: By hooking functions like malloc, free, and various syscalls (e.g., read, write), 5e updates the shadow map. If a program attempts to read uninitialized memory or access memory outside of its allocated bounds, the emulator pauses the program, allowing for real-time debugging.
• 13:01 Current Limitations (Work in Progress): The current 5e implementation has limitations. It struggles to accurately determine and clear stack space upon function returns, potentially missing bugs. It also doesn't handle the ape allocator or automatically add "red zones" (gaps) around variables to catch subtle out-of-bounds accesses.
• 16:38 Future Vision: Linker Integration: Bernstein proposes a significant architectural shift: moving the memory instrumentation from the emulator directly into the linker. This would leverage the linker's precise knowledge of memory layout and stack space, leading to more efficient checks.
• 19:23 Performance Trade-offs: While emulator-based detection can be 100x slower, a linker-based approach is projected to be closer to a 2-3x slowdown (similar to ASan in production). However, this improvement comes at the cost of significantly larger binary sizes due to the embedded instrumentation code.