University of Pennsylvania ScholarlyCommons Departmental Papers (CIS) Department of Computer & Information Science 1-2010 CETS: Compiler-Enforced Temporal Safety for C Santosh Nagarakatte University of Pennsylvania Jianzhou Zhao University of Pennsylvania Milo Martin University of Pennsylvania, [email protected] Stephan A. Zdancewic University of Pennsylvania, [email protected] Follow this and additional works at: https://repository.upenn.edu/cis_papers Part of the Computer Sciences Commons Recommended Citation Santosh Nagarakatte, Jianzhou Zhao, Milo Martin, and Stephan A. Zdancewic, "CETS: Compiler-Enforced Temporal Safety for C", . January 2010. Santosh Nagarakatte, Jianzhou Zhao, Milo M. K. Martin, and Steve Zdancewic. CETS: Compiler-Enforced Temporal Safety for C. In Proceedings of the ACM International Symposium on Memory Management (ISMM), 2010. doi>10.1145/1806651.1806657 © ACM, 2010. This is the author's version of the work. It is posted here by permission of ACM for your personal use. Not for redistribution. The definitive version was published in Proceedings of the ACM International Symposium on Memory Management , {VOL#, ISS#, (DATE)} http://doi.acm.org/10.1145/1806651.1806657 This paper is posted at ScholarlyCommons. https://repository.upenn.edu/cis_papers/576 For more information, please contact [email protected]. CETS: Compiler-Enforced Temporal Safety for C Abstract Temporal memory safety errors, such as dangling pointer dereferences and double frees, are a prevalent source of software bugs in unmanaged languages such as C. Existing schemes that attempt to retrofit temporal safety for such languages have high runtime overheads and/or are incomplete, thereby limiting their effectiveness as debugging aids. This paper presents CETS, a compile-time transformation for detecting all violations of temporal safety in C programs. Inspired by existing approaches, CETS maintains a unique identifier with each object, associates this metadata with the pointers in a disjoint metadata space to retain memory layout compatibility, and checks that the object is still allocated on pointer dereferences. A formal proof shows that this is sufficiento t provide temporal safety even in the presence of arbitrary casts if the program contains no spatial safety violations. Our CETS prototype employs both temporal check removal optimizations and traditional compiler optimizations to achieve a runtime overhead of just 48% on average. When combined with a spatial-checking system, the average overall overhead is 116% for complete memory safety. Disciplines Computer Sciences Comments Santosh Nagarakatte, Jianzhou Zhao, Milo M. K. Martin, and Steve Zdancewic. CETS: Compiler-Enforced Temporal Safety for C. In Proceedings of the ACM International Symposium on Memory Management (ISMM), 2010. doi>10.1145/1806651.1806657 © ACM, 2010. This is the author's version of the work. It is posted here by permission of ACM for your personal use. Not for redistribution. The definitive version was published in Proceedings of the ACM International Symposium on Memory Management , {VOL#, ISS#, (DATE)} http://doi.acm.org/ 10.1145/1806651.1806657 This conference paper is available at ScholarlyCommons: https://repository.upenn.edu/cis_papers/576 CETS: Compiler-Enforced Temporal Safety for C Santosh Nagarakatte Jianzhou Zhao Milo M. K. Martin Steve Zdancewic Computer and Information Sciences Department, University of Pennsylvania [email protected] [email protected] [email protected] [email protected] Abstract Heap based Stack based Temporal memory safety errors, such as dangling pointer derefer- int *p, *q, *r; int* q; ences and double frees, are a prevalent source of software bugs in p = malloc(8); void foo() { unmanaged languages such as C. Existing schemes that attempt to ... int a; retrofit temporal safety for such languages have high runtime over- q = p; q = &a; heads and/or are incomplete, thereby limiting their effectiveness as ... } debugging aids. This paper presents CETS, a compile-time trans- formation for detecting all violations of temporal safety in C pro- free(p); int main() { grams. Inspired by existing approaches, CETS maintains a unique r = malloc(8); int *q; identifier with each object, associates this metadata with the point- ... foo(); ers in a disjoint metadata space to retain memory layout compati- ... = *q; ... = *q; bility, and checks that the object is still allocated on pointer deref- } erences. A formal proof shows that this is sufficient to provide tem- Figure 1. Dangling pointer errors involving the heap and stack. poral safety even in the presence of arbitrary casts if the program On the left, freeing causes to become a dangling pointer. The contains no spatial safety violations. Our CETS prototype employs p q memory pointed to by could be reallocated by any subsequent both temporal check removal optimizations and traditional com- q call to . On the right, assigns the address of stack- piler optimizations to achieve a runtime overhead of just 48% on malloc() foo() allocated variable to global variable . After returns, its average. When combined with a spatial-checking system, the aver- a q foo() stack frame is popped, thereby points to a stale region of the age overall overhead is 116% for complete memory safety. q stack, which any intervening function call could alter. In both cases, Categories and Subject Descriptors D.3.3.4 [Programming Lan- dereferencing q can result in garbage values or data corruption. guages]: Processors; D.2.5 [Software Engineering]: Testing and Debugging ple times), and invalid frees (calling free() with a non-heap ad- General Terms Languages, Performance, Security, Reliability dress or pointer to the middle of a heap-allocated region). Figure 1 shows two examples of common kinds of temporal memory safety Keywords memory safety, temporal errors, dangling pointers, C errors, including a dangling reference to a re-allocated heap loca- tions (left) and a dangling pointer to the stack (right). 1. Introduction Although there has been considerable effort in detecting tem- poral errors [6, 14, 15, 18, 25, 26, 28], challenges remain. For ex- Unmanaged languages such as C/C++ are the de facto standard for ample, consider the widely used Valgrind Memcheck tool [25]. Al- implementing operating systems, virtual machine monitors, lan- though an important debugging aid, Memcheck fails to detect dan- guage runtimes, database management systems, embedded soft- gling pointers to reallocated data locations, and it exhibits runtime ware, and performance-critical software of all kinds. Such lan- overheads in excess of 10x [25], partly due to its use of dynamic guages provide low-level control of memory layout, explicit mem- binary instrumentation. Other approaches modify malloc() to al- ory management, and proximity to the underlying hardware. How- locate only one object per page and unmap the page at deallocation ever, all of this control comes at a price—lack of bounds check- time, thus using the processor’s virtual address translation hard- ing leads to buffer overflows (spatial safety violations) and manual ware to detect dangling pointers dereferences. For programs with memory management leads to dangling pointer and double-free er- many small objects, this approach can inflate memory use dramati- rors (temporal safety violations). Both types of memory errors can cally (e.g., allocating a 4k page for a 40-byte object causes a 100x result in crashes, silent data corruption, and severe security vulner- increase in memory footprint). Recent work has reduced physical abilities. Recognizing the gravity of the problem, there have been memory usage [14], but such approaches do not detect dangling ref- many proposals for detecting or preventing one or both kinds of erences to stack locations, and the system calls per allocation/deal- errors [4–6, 9, 10, 13–15, 18–20, 22, 23, 25–28, 30, 31]. location can results in significant runtime overheads for programs This paper focuses on debugging tools for runtime prevention that frequently allocate memory [14]. Conservative garbage collec- of temporal safety violations. Temporal safety errors include: dan- tion side-steps this problem for heap allocations, however it also gling pointer dereferences (referencing an object that has been deal- fails to detect dangling pointers to the stack, and it is not suitable located), double free’s (calling free() on the same object multi- for all applications domains. Furthermore, it typically masks such errors (rather than reporting them), which is less useful in the con- Permission to make digital or hard copies of all or part of this work for personal or text of a debugging tool. classroom use is granted without fee provided that copies are not made or distributed Overall, prior proposals suffer from one or more of the follow- for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute ing deficiencies: high runtime overheads, high memory overheads, to lists, requires prior specific permission and/or a fee. failure to detect all temporal errors (for example, to the stack, to re- ISMM’10, June 5–6, 2010, Toronto, Ontario, Canada. allocated heap locations, or in the face of arbitrary casts), requiring Copyright c 2010 ACM 978-1-4503-0054-4/10/06. $10.00 annotations inserted by the programmer, or altering memory layout (which breaks compatibility with existing C code). These draw- ences. However, if a location