Sound garbage collection for C using pointer provenance

Abstract

Garbage collection (GC) support for unmanaged languages can reduce programming burden in reasoning about liveness of dynamic objects. It also avoids temporal memory safety violations and memory leaks. Sound GC for weakly-typed languages such as C/C++, however, remains an unsolved problem. Current value-based GC solutions examine values of memory locations to discover the pointers, and the objects they point to. The approach is inherently unsound in the presence of arbitrary type casts and pointer manipulations, which are legal in C/C++. Such language features are regularly used, especially in low-level systems code. In this paper, we propose Dynamic Pointer Provenance Tracking to realize sound GC. We observe that pointers cannot be created out-of-thin-air, and they must have provenance to at least one valid allocation. Therefore, by tracking pointer provenance from the source (e.g., malloc) through both explicit data-flow and implicit control-flow, our GC has sound and precise information to compute the set of all reachable objects at any program state. We discuss several static analysis optimizations, that can be employed during compilation aided with profiling, to significantly reduce the overhead of dynamic provenance tracking from nearly 8× to 16% for well-behaved programs that adhere to the C standards. Pointer provenance based sound GC invocation is also 13% faster and reclaims 6% more memory on average, compared to an unsound value-based GC.

MineSweeper: a “clean sweep” for drop-in use-after-free prevention

“…MineSweeper preserves compatibility with hidden and misaligned pointers; while these are rare, they are common enough that not supporting them breaks real programs [2]. MineSweeper achieves this by not freeing anything the programmer has not requested to be freed, unlike garbage collectors [8], which are unsafe in C/C++ without additional provenance tracking and sticking strictly to the C/C++ standard [5], and significantly more expensive than MineSweeper [2,5]. It gives no additional security guarantees for objects whose only pointers are hidden.…”

“…The sweep is largely independent of the application thread: to limit its performance impact, we can run it concurrently with the application. Still, the sweep should see a consistent picture of memory to avoid pointers being lost 5 .…”

Automatic inspection of program state in an uncooperative environment

“…With this goal in mind, we bring, from the systems community into the software engineering community techniques to create Program Inspection Points, a notion that we define in Section 2. Like in classic garbage collectors for C/C++, [6][7][8][9][10] inspection points impose no overhead on programs unless they need to be inspected; Moreover, like in that line of work, we are willing to accept some imprecision: the inability to distinguish pointers from integers, for instance, might prevent the inspection of some parts of the heap. Yet, in contrast to garbage collectors, we provide the program with the means to associate low-level data-heap and stack allocated memory, for instance-with high-level source-code information: user-defined names and line locations.…”

“…5 They own this qualifier to a weak type system, that neither associates size information with memory regions, nor distinguish pointers from scalars. Although there exist garbage collectors for languages like C or C++, [6][7][8][9][10] such implementations are not mainstream. The more reliable these garbage collectors are, the heavier their overhead.…”

“…* We use the same assumption as Banerjee et al:10 heap-allocated addresses only come out as the return value of particular functions like malloc, calloc, and so forth. Section 4 provides the complete list.…”