automatically tolerating and correcting memory errors
DESCRIPTION
Applications written in unsafe languages like C and C++ are vulnerable to memory errors such as buffer overflows, dangling pointers, and reads of uninitialized data. These errors, which lead to program crashes, security vulnerabilities, and unpredictable behavior, are both difficult to avoid and costly to repair. This talk presents two systems that automatically harden unaltered C and C++ programs against heap-based memory errors. The first, DieHard, uses randomization and replication to make programs probabilistically resistant to a wide range of memory errors. Instead of crashing or running amok, DieHard lets programs run correctly in the face of memory errors with high probability. DieHard trades a modest increase in memory consumption (and optionally, the extra processing power of multicore CPUs) for dramatically increased reliability. While DieHard tolerates errors, our second system, Exterminator, automatically isolates and corrects them. Exterminator exploits randomization to pinpoint errors with high precision. From this information, Exterminator generates patches that fix these errors in current and subsequent executions. In addition, Exterminator enables collaborative bug correction by merging patches generated by multiple users.TRANSCRIPT
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
Automatically Tolerating &Correcting Memory Errors
Emery BergerUniversity of Massachusetts Amherst
joint work with Gene Novark (UMass Amherst),Ben Zorn (Microsoft Research)
[PLDI 2006, PLDI 2007]
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
Problems with Unsafe Languages
C, C++: pervasive apps, but langs.memory unsafe
Numerous opportunities for security vulnerabilities, errors Double free Invalid free Uninitialized reads Dangling pointers Buffer overflows (stack & heap)
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
Current Approaches
Unsound, may work or abort Windows, GNU libc, etc., Rx [Zhou]
Unsound, will definitely continue Failure oblivious [Rinard]
Sound, definitely aborts (fail-safe) CCured [Necula], CRED [Ruwase & Lam], SAFECode
[Dhurjati, Kowshik & Adve], etc. Slowdowns: 30% - 20X Requires C source, programmer intervention Garbage collection or partially sound (pools)
Good for debugging, less for deployment
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
Soundness for “Erroneous” Programs
Normally: memory errors ? Consider infinite-heap allocator:
All news fresh;ignore delete
No dangling pointers, invalid frees,double frees
Every object infinitely large No buffer overflows, data overwrites
Transparent to correct program “Erroneous” programs sound
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
Probabilistic Memory Safety
Approximate with M-heaps (e.g., M=2)
DieHard: fully-randomized M-heap Increases odds of benign errors Probabilistic memory safety
i.e., P(no error) n Errors independent across heaps
E(users with no error) n * |users|
? Efficient implementation…
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
Implementation Choices
Conventional, freelist-based heaps Hard to randomize, protect from errors
Double frees, heap corruption What about bitmaps? [Wilson90]
– Catastrophic fragmentation Each small object likely to occupy one page
obj obj objobj
pages
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
Randomized Heap Layout
Bitmap-based, segregated size classes Bit represents one object of given size
i.e., one bit = 2i+3 bytes, etc. Prevents fragmentation
00000001 1010 10
size = 2i+3 2i+
4
2i+
5
metadata
heap
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
Randomized Allocation
malloc(8): compute size class = ceil(log2 sz) – 3 randomly probe bitmap for zero-bit (free)
Fast: runtime O(1) M=2 E[# of probes] ≈ 2
00000001 1010 10
size = 2i+3 2i+
4
2i+
5
metadata
heap
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
malloc(8): compute size class = ceil(log2 sz) – 3 randomly probe bitmap for zero-bit (free)
Fast: runtime O(1) M=2 E[# of probes] ≈ 2
00010001 1010 10
size = 2i+3 2i+
4
2i+
5
metadata
heap
Randomized Allocation
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
free(ptr): Ensure object valid – aligned to right address Ensure allocated – bit set Resets bit
Prevents invalid frees, double frees
00010001 1010 10
size = 2i+3 2i+
4
2i+
5
metadata
heap
Randomized Deallocation
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
Randomized Deallocation
free(ptr): Ensure object valid – aligned to right address Ensure allocated – bit set Resets bit
Prevents invalid frees, double frees
00010001 1010 10
size = 2i+3 2i+
4
2i+
5
metadata
heap
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
free(ptr): Ensure object valid – aligned to right address Ensure allocated – bit set Resets bit
Prevents invalid frees, double frees
00000001 1010 10
size = 2i+3 2i+
4
2i+
5
metadata
heap
Randomized Deallocation
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
Randomized Heaps & Reliability
2 34 5 3 1 6
object size = 2i+4
object size = 2i+3
…
11 6 3 2 5 4 …
My Mozilla: “malignant” overflow
Your Mozilla: “benign” overflow
Objects randomly spread across heap Different run = different heap
Improves security Errors across heaps independent
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
DieHard software architecture
broadcast vote
input output
execute replicas(separate processes)
replica3seed3
replica1seed1
replica2seed2
Optional: replication-based fault-tolerance Requires randomization: errors independent
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
DieHard Results
Analytical results (pictures!) Dangling pointer errors Buffer overflows Uninitialized reads
Empirical results Runtime overhead Error avoidance
Injected faults & actual applications
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
Analytical Results: Dangling Pointers
Free one object too early
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
Analytical Results: Dangling Pointers
Free one object too early
Object extremely unlikely to be reused soon
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
Analytical Results: Dangling Pointers
Free one object too early
Object extremely unlikely to be reused soon
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
Analytical Results: Dangling Pointers
Free one object too early
Object extremely unlikely to be reused soon
Example: F = 1,000,000 P(ok after one malloc) ¼ 1 P(ok after 1000 mallocs) ¸ 99.9%
F = # free objectsA = # mallocs
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
Analytical Results: Buffer Overflows
Model overflow: random write of live data Heap half full (max occupancy)
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
Analytical Results: Buffer Overflows
Model overflow: random write of live data Heap half full (max occupancy)
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
Analytical Results: Buffer Overflows
Model overflow: random write of live data Heap half full (max occupancy)
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
Analytical Results: Buffer Overflows
Replicas: Increase odds of avoiding overflow in at least one replica
repl
icas
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
Analytical Results: Buffer Overflows
Replicas: Increase odds of avoiding overflow in at least one replica
repl
icas
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
Analytical Results: Buffer Overflows
Replicas: Increase odds of avoiding overflow in at least one replica
repl
icas
P(Overflow in all replicas) = (½)3 = 1/8 P(No overflow in ≥ 1 replica) = 1-(½)3 = 7/8
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
Analytical Results: Buffer Overflows
F = free spaceH = heap sizeN = # objects
worth of overflow
k = replicas
Overflow one object
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
Empirical Results: Error Avoidance
Injected faults: Dangling pointers (@50%, 10 allocations)
glibc: crashes; DieHard: 9/10 correct Overflows (@1%, 4 bytes over) –
glibc: crashes 9/10, “inf loop”; DieHard: 10/10 correct Real faults:
Avoids Squid web cache overflow Crashes BDW & glibc
Avoids dangling pointer error in Mozilla DoS in glibc & Windows
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
DieHard Limitations
Fine for single error But: multiple errors eventually swamp
probabilistic protection Not great for large overflows
Tolerates errors But doesn’t find them
No information for programmer Ideal: point directly to bug…
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
Exterminator:Automatically Correcting
Memory Errors with High Probability
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
Diagnosing Buffer Overflows
Canonical buffer overflow: Allocate object – too small Write past end ) nukes object bytes forward
Not necessarily contiguous
char * str = new char[8];strcpy (str, “goodbye cruel world”);
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
Diagnosing Buffer Overflows
Canonical buffer overflow: Allocate object – too small Write past end ) nukes object bytes forward
Not necessarily contiguous
char * str = new char[8];strcpy (str, “goodbye cruel world”);
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
Diagnosing Buffer Overflows
Canonical buffer overflow: Allocate object – too small Write past end ) nukes object bytes forward
Not necessarily contiguous
bad object(too small)
char * str = new char[8];strcpy (str, “goodbye cruel world”);
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
Diagnosing Buffer Overflows
Canonical buffer overflow: Allocate object – too small Write past end ) nukes object bytes forward
Not necessarily contiguous
bad object(too small)
bytes past end
char * str = new char[8];strcpy (str, “goodbye cruel world”);
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
Diagnosing Buffer Overflows
Canonical buffer overflow: Allocate object – too small Write past end ) nukes object bytes forward
Not necessarily contiguous
bad object(too small)
bytes past end
char * str = new char[8];strcpy (str, “goodbye cruel world”);
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
Diagnosing Buffer Overflows
Canonical buffer overflow: Allocate object – too small Write past end ) nukes object bytes forward
Not necessarily contiguous
bytes past end
char * str = new char[8];strcpy (str, “goodbye cruel world”);
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
Diagnosing Buffer Overflows
Canonical buffer overflow: Allocate object – too small Write past end ) nukes object bytes forward
Not necessarily contiguous
bytes past end
char * str = new char[8];strcpy (str, “goodbye cruel world”);
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
Diagnosing Buffer Overflows
Canonical buffer overflow: Allocate object – too small Write past end ) nukes object bytes forward
Not necessarily contiguous
bytes past end
char * str = new char[8];strcpy (str, “goodbye cruel world”);
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
Diagnosing Buffer Overflows
Canonical buffer overflow: Allocate object – too small Write past end ) nukes object bytes forward
Not necessarily contiguous
bytes past end
char * str = new char[8];strcpy (str, “goodbye cruel world”);
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
Diagnosing Buffer Overflows
Canonical buffer overflow: Allocate object – too small Write past end ) nukes object bytes forward
Not necessarily contiguous
bytes past end
char * str = new char[8];strcpy (str, “goodbye cruel world”);
1. Heap provides no useful information
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
Diagnosing Buffer Overflows
Canonical buffer overflow: Allocate object – too small Write past end ) nukes object bytes forward
Not necessarily contiguous
bytes past end
char * str = new char[8];strcpy (str, “goodbye cruel world”);
2. No way to detect corruption
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
Isolating Buffer Overflows
8 2 9 3 4 5 1 7
Red =possiblebadobject
Green =notbadobject
Canaries in freed space detect corruption
known random value dead canary = corruption
# = object id (allocation time)
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
Isolating Buffer Overflows
8 2 9 3 4 5 1 7
Red =possiblebadobject
Green =notbadobject
Canaries in freed space detect corruption Run multiple times with “DieFast” allocator
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
Canaries in freed space detect corruption Run multiple times with “DieFast” allocator
8 2 9 3 4 5 1 7
Isolating Buffer Overflows
Red =possiblebadobject
Green =notbadobject
1 8 7 5 3 2 9 6 4
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
Canaries in freed space detect corruption Run multiple times with “DieFast” allocator Key insight: Overflow must be at same
8 2 9 3 4 5 1 7
Isolating Buffer Overflows
Red =possiblebadobject
Green =notbadobject
1 8 7 5 3 2 9 6 4
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
8 2 9 4 5 1 7
Isolating Buffer Overflows
Red =possiblebadobject
Green =notbadobject
1 8 7 5 3 2 9 6 4
3
Canaries in freed space detect corruption Run multiple times with “DieFast” allocator Key insight: Overflow must be at same
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
8 2 9 3 4 5 1 7
Isolating Buffer Overflows
Red =possiblebadobject
Green =notbadobject
1 8 7 5 3 2 9 6 4
Canaries in freed space detect corruption Run multiple times with “DieFast” allocator Key insight: Overflow must be at same
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
8 2 9 3 4 5 1 7
Isolating Buffer Overflows
Red =possiblebadobject
Green =notbadobject
1 8 7 5 3 6 492
Canaries in freed space detect corruption Run multiple times with “DieFast” allocator Key insight: Overflow must be at same
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
Isolating Buffer Overflows
8 2 9 3 4 5 1 7
Red =possiblebadobject
Green =notbadobject
1 8 7 5 3 2 9 6 4
4 9 6 38 5 72 1
Canaries in freed space detect corruption Run multiple times with “DieFast” allocator Key insight: Overflow must be at same
) object 9 overflowed, with high probability
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
Buffer Overflow Analysis
Example: H = 1,000,000 objects3 iterations ¼ false positives
Iterations exponentially increase precision
H = # heap objectsK = # iterations
11;000;000
8 2 9 3 4 5 1 7
1 8 7 5 3 2 9 6 4
4 9 6 38 5 72 1
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
Isolating Dangling Pointers
Dangling pointer error: Allocated object freed too soon Overwritten by some other object
int * v = new int[4];…delete [] v; // oops…char * str = new char[16];strcpy (str, “die, pointer”);v[3] = 12;… use of v[0]
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
Isolating Dangling Pointers
Unlike buffer overflow: dangling pointer ) same corruption in all
k = 3 ) false negatives ¼P(identical over°ow) ·
µS
H ¡ 1
¶k¡ 1
11;000;000
2
11 2 3 6 4 5 10 1 12 798
1 7 5 3 2 1112 648 9 10
4 6 312 5 72 1410 8 9
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
Correcting Allocator
Generate runtime patches to correct errors Track object call sites in allocator
Prevent overflows: pad overflowed objects
malloc(8) malloc(8 + δ)
Prevent dangling pointers: defer freesfree(ptr) delay δ mallocs;
free(ptr)
1 1
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
Exterminator Summary
Three main pieces: DieHard-based allocator (DieFast)
Reveals bugs Error isolator
Finds bugs across multiple heaps w.h.p. Correcting allocator
Fixes bugs Modes suitable for testing (debugging)
or deployment
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
Exterminator Modes
Iterative Run multiple times Same inputs Debugging
Replicated Run simultaneously Deployable w/limitations Can fix errors on-the-fly
Cumulative Different inputs, nondeterminism Deployable; see paper for details
seed
votebroadcast
input output
DieFast replica1seed
DieFast replica2seed
Error isolator
correcting allocator
correcting allocator
correcting allocator
DieFast replica3
runtime patches
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
Exterminator Runtime Overhead
25%
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
Empirical Results: Real Faults
Squid heap overflow Crashes glibc 2.8.0 and BDW collector 3 iterations to fix ) 6 byte pad
Prevents overflow for all subsequent executions
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
Mozilla 1.7.3 buffer overflow Debug scenario:
repeated load of PoC: 23 runs to fix overflow
Deployed scenario: different browsing sessions: 34 runs to fix
2
Empirical Results: Real Faults
31
1
2
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
Conclusion Randomization: enables
probabilistic memory safety (DieHard)& automatic error correction (Exterminator)
Trades hardware resources(RAM,CPU) for reliability Hardware trends
Larger memories, multi-core CPUs Follows in footsteps of
ECC memory, RAID
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
The End
www.diehard-software.orgwww.cs.umass.edu/~emery
UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007
4 3 6 5218
16
allocation space
bitmap
1
object size
2inUse
4inUse
1inUse
6inUse
1inUse
miniheaps
Actual DieHard Heap Layout
Bitmap-based, segregated size classes Bit represents one object of given size
i.e., one bit = 2i+3 bytes, etc.
malloc(): randomly probe bitmap for free space free(): just reset bit