TUM Logo

Fault-tolerant Memory Safety with LLVM

Fault-tolerant Memory Safety with LLVM

Supervisor(s): Dr. Julian Horsch, Dieter Schuster
Status: finished
Topic: Others
Author: Benjamin Orthen
Submission: 2021-02-15
Type of Thesis: Masterthesis
Thesis topic in co-operation with the Fraunhofer Institute for Applied and Integrated Security AISEC, Garching

Description

For more than thirty years, programmers have been using memory-unsafe
languages such as C and C++ due to their performance and low-level memory
interaction features, but equally long, memory errors have plagued programs
written in these languages.
Sanitizers promise to solve this problem by providing runtime memory safety
without requiring manual changes by the developer. In general, sanitizers abort
a program when they detect a memory error.
However, in failure-critical environments, this “fail-stop” behavior
might be undesirable when availability is highly prioritized. We present Fault-Tolerant
Memory Safety (FTMS), an approach that provides fault-tolerant memory safety for spatial
and for temporal memory errors, and with which programs can mitigate memory errors without
having to stop their execution. FTMS implements a modular approach, combining a mechanism to
detect memory errors and a mechanism which handles the detected memory errors by applying a
fault-tolerance policy, i.e., a strategy that describes how to tolerate memory errors. FTMS
contains two policies which differ in their approach and complexity.
Failure-Obliviousness (FO) ignores all invalid writes and manufactures return values for
invalid reads, while Invalid Memory Accesses Store (IMAS) stores invalid writes to and
retrieves invalid reads from an extra structure that acts like a separate address space for
each memory object. FTMS’s prototype implements our concept as a compiler pass together with
a runtime library in LLVM, using SoftBoundCETS as detection mechanism. Our evaluation shows
that FTMS can prevent real-world security vulnerabilities and enable the affected programs
to continue executing after having mitigated the memory error, while having a performance
overhead on selected SPEC benchmarks of 459%, compared to an overhead of 283% for SoftBoundCETS.