Die Hard Probabilistic Memory Safety for Unsafe Programming
Die. Hard: Probabilistic Memory Safety for Unsafe Programming Languages Emery Berger University of Massachusetts Amherst Ben Zorn Microsoft Research UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science • PLDI 2006
Problems with Unsafe Languages n n C, C++: pervasive apps, but langs. memory unsafe Numerous opportunities for security vulnerabilities, errors n n n Double free Invalid free Uninitialized reads Dangling pointers Buffer overflows (stack & heap) UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science • PLDI 2006
Current Approaches n Unsound, may work or abort n n Unsound, will definitely continue n n Windows, GNU libc, etc. , Rx [Zhou] Failure oblivious [Rinard] Sound, definitely aborts (fail-safe) n CCured [Necula], CRED [Ruwase & Lam], SAFECode [Dhurjati, Kowshik & Adve] n n n Requires C source, programmer intervention 30% to 20 X slowdowns Good for debugging, less for deployment UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science • PLDI 2006
Probabilistic Memory Safety Die. Hard: correct execution in face of errors with high probability n Fully-randomized memory manager n n n Increases odds of benign memory errors Ensures different heaps across users Replication n Run multiple replicas simultaneously, vote on results n n Detects crashing & non-crashing errors Trades space for increased reliability UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science • PLDI 2006
Soundness for “Erroneous” Programs n n Normally: memory errors ) ? … Consider infinite-heap allocator: n All news fresh; ignore delete n n Every object infinitely large n n n No dangling pointers, invalid frees, double frees No buffer overflows, data overwrites Transparent to correct program “Erroneous” programs sound UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science • PLDI 2006
Approximating Infinite Heaps n Infinite ) M-heaps: probabilistic soundness n Pad allocations & defer deallocations + Simple – No protection from larger overflows – pad = 8 bytes, overflow = 9 bytes… – Deterministic: overflow crashes everyone n Better: randomize heap + Probabilistic protection against errors + Independent across heaps ? Efficient implementation… UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science • PLDI 2006
Implementation Choices n Conventional, freelist-based heaps n Hard to randomize, protect from errors n n Double frees, heap corruption What about bitmaps? [Wilson 90] – Catastrophic fragmentation n Each small object likely to occupy one page obj obj pages UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science • PLDI 2006 obj
Randomized Heap Layout 00000001 1010 10 size = 2 i+3 2 i+4 metadata 2 i+5 heap n Bitmap-based, segregated size classes n Bit represents one object of given size n n i. e. , one bit = 2 i+3 bytes, etc. Prevents fragmentation UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science • PLDI 2006
Randomized Allocation 00000001 1010 10 size = 2 i+3 2 i+4 metadata 2 i+5 heap malloc(8): n n n compute size class = ceil(log 2 sz) – 3 randomly probe bitmap for zero-bit (free) Fast: runtime O(1) n M=2 ) E[# of probes] · 2 UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science • PLDI 2006
Randomized Allocation 0001 1010 10 size = 2 i+3 2 i+4 metadata 2 i+5 heap malloc(8): n n n compute size class = ceil(log 2 sz) – 3 randomly probe bitmap for zero-bit (free) Fast: runtime O(1) n M=2 ) E[# of probes] · 2 UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science • PLDI 2006
Randomized Deallocation 0001 1010 10 size = 2 i+3 2 i+4 metadata 2 i+5 heap n free(ptr): n n Ensure object valid – aligned to right address Ensure allocated – bit set Resets bit Prevents invalid frees, double frees UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science • PLDI 2006
Randomized Deallocation 0001 1010 10 size = 2 i+3 2 i+4 metadata 2 i+5 heap n free(ptr): n n Ensure object valid – aligned to right address Ensure allocated – bit set Resets bit Prevents invalid frees, double frees UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science • PLDI 2006
Randomized Deallocation 00000001 1010 10 size = 2 i+3 2 i+4 metadata 2 i+5 heap n free(ptr): n n Ensure object valid – aligned to right address Ensure allocated – bit set Resets bit Prevents invalid frees, double frees UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science • PLDI 2006
Randomized Heaps & Reliability object size = 2 i+3 2 4 5 3 object size = 2 i+4 1 6 … 3 My Mozilla: “malignant” overflow n n Objects randomly spread across heap Different run = different heap n Errors across heaps independent Your Mozilla: “benign” overflow 1 6 3 2 5 4 1 UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science • PLDI 2006 …
Die. Hard software architecture seed 1 input seed 2 replica 1 output replica 2 vote broadcast seed 3 replica 3 execute replicas n Each replica has different allocator n “Output equivalent” – kill failed replicas UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science • PLDI 2006
Results n Analytical results (pictures!) n n Buffer overflows Dangling pointer errors Uninitialized reads Empirical results n n Runtime overhead Error avoidance n Injected faults & actual applications UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science • PLDI 2006
Analytical Results: Buffer Overflows n Model overflow as write of live data n Heap half full (max occupancy) UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science • PLDI 2006
Analytical Results: Buffer Overflows n Model overflow as write of live data n Heap half full (max occupancy) UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science • PLDI 2006
Analytical Results: Buffer Overflows n Model overflow as write of live data n Heap half full (max occupancy) UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science • PLDI 2006
Analytical Results: Buffer Overflows Replicas: Increase odds of avoiding overflow in at least one replicas n UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science • PLDI 2006
Analytical Results: Buffer Overflows Replicas: Increase odds of avoiding overflow in at least one replicas n UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science • PLDI 2006
Analytical Results: Buffer Overflows Replicas: Increase odds of avoiding overflow in at least one replicas n n n P(Overflow in all replicas) = (1/2)3 = 1/8 P(No overflow in ¸ 1 replica) = 1 -(1/2)3 = 7/8 UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science • PLDI 2006
Analytical Results: Buffer Overflows n n F = free space H = heap size N = # objects worth of overflow k = replicas n Overflow one object UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science • PLDI 2006
Empirical Results: Runtime UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science • PLDI 2006
Empirical Results: Runtime UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science • PLDI 2006
Empirical Results: Error Avoidance n Injected faults: n Dangling pointers (@50%, 10 allocations) n n Overflows (@1%, 4 bytes over) – n n glibc: crashes; Die. Hard: 9/10 correct glibc: crashes 9/10, inf loop; Die. Hard: 10/10 correct Real faults: n Avoids Squid web cache overflow n n Crashes BDW & glibc Avoids dangling pointer error in Mozilla n Do. S in glibc & Windows UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science • PLDI 2006
Conclusion n Randomization + replicas = probabilistic memory safety n n n Improves over today (0%) Useful point between absolute soundness (fail-stop) and unsound Trades hardware resources (RAM, CPU) for reliability n Hardware trends n n Larger memories, multi-core CPUs Follows in footsteps of ECC memory, RAID UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science • PLDI 2006
Die. Hard software http: //www. cs. umass. edu/~emery/diehard n n Linux, Solaris (stand-alone & replicated) Windows (stand-alone only) UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science • PLDI 2006
- Slides: 28