1 / 25

Shimin Chen LBA Reading Group Presentation

Archipelago: Trading Address Space for Reliability and Security V.B. Lvin, G. Novark, E.D. Berger (UMASS), B.G. Zorn (MSR). ASPLOS’08. Shimin Chen LBA Reading Group Presentation. Motivation. Memory errors in C/C++ programs Difficult to debug, easy to exploit

ulfah
Télécharger la présentation

Shimin Chen LBA Reading Group Presentation

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. Archipelago: Trading Address Space for Reliability and SecurityV.B. Lvin, G. Novark, E.D. Berger (UMASS), B.G. Zorn (MSR). ASPLOS’08. Shimin Chen LBA Reading Group Presentation

  2. Motivation • Memory errors in C/C++ programs • Difficult to debug, easy to exploit • Existing approaches not sufficient • Testing tools: valgrind, purify -- overhead • Conservative garbage collectors – no buffer overflow protection • Compiler-based approaches: need source code, runtime overhead/programmer intervention

  3. This Paper • Idea: • 64-bit machine, large virtual address space • Allocate one object per page • Ensure the distance between objects is large • “Archipelago”: objects are in “islands”

  4. Outline • Introduction • Background • Archipelago Architecture • Evaluation • Conclusions

  5. unmapped committed reserved Virtual Memory Page State 3.munmap 3.munmap 1.mmap 2.First access: a fresh zero page 4.madvise(MADV_DONTNEED)

  6. Probabilistic Memory Safety • DieHard • Ideal: an infinite heap memory is ideal • Objects are allocated fresh • Infinitely far away from each other • Never deallocated • Probabilistic: M-heap • M times larger than needed • Two objects are separated by M-1 unused objects w/ high prob

  7. Outline • Introduction • Background • Archipelago Architecture • Evaluation • Conclusions

  8. Overall Picture A Pre-loaded library replacing malloc/free etc.

  9. Randomizing Object-Per-Page Allocator

  10. Randomizing Object-Per-Page Allocator • Use mmap to reserve a pool of virtual pages (512MB) • madvise(MADV_RANDOM) • Pages are instantiated upon actual use • A bitmap: free/allocated • Allocation: randomly pick one page • Ensure the pool is at most half full • Bounds worst-case expected probes

  11. Large objects Randomize in-page offset for CPU cache performance

  12. Hot Object Space + Cold Storage

  13. Hot Object Space + Cold Storage • Problem: cannot afford a page per object • Observation: working set hypothesis • Solution: • Hot object per page: keep a fixed number • Cold object compacted • Saved in conventional heap • The virtual page is marked as not accessible, then released back to OS • Detect access then inflate it by segfault handler

  14. Hot Object Space Details • FIFO queue for hot object pages • size configurable, default 5000 objects • Allocation: enqueue to tail • Queue Full: compact the head object • Access a compacted page: enqueue to tail

  15. Cold Storage More Details • When compacting, detect the actual size of the object by scanning the page backwards until first non-zero • Overflowed buffer is copied correctly • mprotect(page, PROT_NONE) • madvise(page, MADV_DONTNEED)

  16. Outline • Introduction • Background • Archipelago Architecture • Evaluation • Conclusions

  17. Experimental Setup • Dual-processor (chip), 4-core/processor, 64-bit Intel Xeon at 2.33 Ghz • 4MB L2 cache • 8GB RAM • Linux kernel 2.6.22-rc2-mm1 • This version performs madvise lazily thus boost Archipelago’s performance • Compare against GNU Libc, and DieHard

  18. Sever Applications (loopback network interface) About 2,000 ~ 10,000 objects per second Normalized performance

  19. Memory Intensive espresso(allocate 1.5 million objects per second)

  20. Varying Hot Space Size (espresso)

  21. Varying Virtual Address Pool Size

  22. Injected Faults Free x allocations earlier 0.01~thousands faults, 0.001~hundreds faults, 0.0001~tens faults

  23. Avoid Real Buffer Overflow • Pine • Squid

  24. Conclusion • Taking advantage of large virtual address space • Object per virtual page • Hot objects use physical pages • Cold objects are compacted

More Related