1 / 18

CETS: Compiler-Enforced Temporal Safety for C

CETS: Compiler-Enforced Temporal Safety for C. Lara Khamisy, Kevin Matthews, and Chris Pratt. Santosh Nagarakatte, Jianzhou Zhao, Milo M. K. Martin, Steve Zdancewic. Introduction. Description : Compiler-enforced temporal safety (CERT) for C programs.

taran
Download Presentation

CETS: Compiler-Enforced Temporal Safety for C

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. CETS: Compiler-Enforced Temporal Safety for C Lara Khamisy, Kevin Matthews, and Chris Pratt Santosh Nagarakatte, Jianzhou Zhao, Milo M. K. Martin, Steve Zdancewic

  2. Introduction • Description:Compiler-enforced temporal safety (CERT) for C programs. • Background: Temporal memory safety errors 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 aid. • Solution:CETS is a pass that will instrument IR to detect all temporal safety violations.

  3. Overview of Memory Violations • Spatial - the pointer refers to the wrong place in the address space • Buffer overflow • Dereference uninitialized pointer • Temporal - the place in the address space is no longer valid • Dangling pointer dereference • Double free Both types of memory errors can result in crashes, silent data corruption, and severe security vulnerabilities.

  4. Examples of Temporal Safety Violations Heap-based int *a, *b; a = malloc(8); … b = a; ... free(a); … … = *b; Stack-based int *a; void foo() { int b; a = &b; } int main() { foo(); … = *a; }

  5. Motivation for Detecting Temporal Safety Violations • C/C++ provide low-level control/management of memory in OS, embedded software, etc • Lack of bounds checking and manual memory management leads to temporal safety violations • Temporal safety violations lead to crashes, silent data corruption, and severe security vulnerabilities

  6. Issues with Other Methods of Detecting Temporal Violations (e.g. Valgrind Memcheck) • High runtime overhead • High memory overhead • Failure to detect all temporal errors • To the stack • Reallocated heap addresses • Arbitrary casts • Requiring annotations inserted by the programmer

  7. Program Instrumentation for Detecting Temporal Safety Violation • Binary Instrumentation • Hardware-assisted Instrumentation • Source-level Instrumentation • Compiler-based Instrumentation

  8. CETS Approach • Compiler-based Instrumentation Apply Optimizations Apply Optimizations Again Apply pass to insert checks C Program Optimized IR with Checks IR with Checks IR of Program

  9. Quick Look at CETS Functionality and Limitations • Functionality • CETS uses compiler based instrumentation. • Identifier based scheme, which assigns a unique key for each allocation region to identify dangling pointers • Pointers are tracked using disjoint shadowspace (in order not to affect the program memory layout) • Limitations • The method does not detect spatial violations • Must be combined with existing spatial safety mechanisms for 100% memory safety.

  10. Lock-and-Key Identifier Based Approach • CETS augments each pointer with two additional word-sized fields: (1) a unique allocation key and (2) a lock address that points to a lock location data Per Pointer Metadata Heap Allocation ptr1 = malloc(size); ptr1_key lock address ptr1 ptr1_key ptr1_key = counter++; ptr1_lock_addr = allocate_lock(); *(ptr1_lock_addr) = ptr1_key; freeable_ptrs_map.insert(ptr1_key, ptr1); lock ptr1_key Memory

  11. Lock-and-Key Identifier Based Approach - Cont. • CETS propagates metadata to newly allocated pointer to the same memory location data Per Pointer Metadata Pointer metadata propagation ptr2 = ptr1 + offset; ptr1_key lock address ptr1 ptr1_key ptr2_key = ptr1_key ptr2_lock_addr = ptr1_lock_addr; ptr1_key lock address ptr2 ptr1_key lock Key1 Memory

  12. Lock-and-Key Identifier Based Approach - Cont. • CETS performs dangling pointer check data Per Pointer Metadata Dangling pointer check if (ptr1_key != *(ptr1_lock_addr) { abort(); } ptr1_key lock address ptr1 ptr1_key ptr1_key lock address value = *ptr1; // original load ptr2 ptr1_key lock ptr1_key Memory

  13. Lock-and-Key Identifier Based Approach - Cont. • Heap deallocation actions data Per Pointer Metadata Heap deallocation if (freeable_ptrs_map.lookup(ptr1_key) != ptr1) { abort(); } freeable_ptrs_map.remove(ptr1_key); ptr1_key lock address ptr1 ptr1_key ptr1_key lock address ptr2 ptr1_key free(ptr1); *(ptr1_lock_addr) = INVALID_KEY; deallocate_lock(ptr1_lock_addr); lock ptr1_key Memory

  14. Call Stack Based Allocation / Deallocation void func() { // Function prologue • To detect dangling pointers to the call stack, a key and corresponding lock address is also associated with each stack frame • This key and lock address pair is given to any pointer derived from the stack pointer (and thus points to an object on the stack). local_key = next_key++; local_lock_addr++; // allocate lock address *(local_lock_addr) = local_key; int var; // local variable ptr = &var; // ptr defined in main ptr_key = local_key; ptr_lock_addr = local_lock_addr; // Function epilogue *(local_lock_addr) = INVALID_KEY; local_lock_addr--; // deallocate lock address }

  15. Benchmarks • The key advantage of compiler based is being able to perform optimizations before and after we insert instrumentation code • No temporal checks are required for any pointer that is directly derived from the stack pointer within the corresponding function call, because the stack frame is guaranteed to live until the function exits • Functional correctness: CETS successfully detected all temporal errors without false violations. • Performance: Overall runtime overhead of 48% • Compared to 77% with alternate implementation • 116% when checking for spatial and temporal • 122% overhead from other checker, such as Valgrind Memcheck

  16. CETS Optimizations • Unnecessary checks • Pointers to globals • Stack pointers within a function call • Redundant checks

  17. Conclusion • CETS is a compiler based temporal safety detection method • It allows for optimizations pre and post instrumentation code addition • It doesn’t change the memory layout of the original program (compared with source code instrumentation methods) • It was run correctly on NIST-SAMATE benchmark and was able to find all temporal errors • By doing post IR instrumentation optimizations passes it was shown to produce 48% overhead, compared with existing methods of 77%.

  18. Thank You Questions?

More Related