1 / 30

Comprehensive Kernel Instrumentation via Dynamic Binary Translation

Comprehensive Kernel Instrumentation via Dynamic Binary Translation. Presenter: Chuong Ngo. Peter Feiner , Angela Demke Brown, Ashvin Goel University of Toronto. No parents, uncles, or girlfriends were killed during the creation of this presentation.

randolph-tripp
Télécharger la présentation

Comprehensive Kernel Instrumentation via Dynamic Binary Translation

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. Comprehensive Kernel Instrumentation via Dynamic Binary Translation Presenter: Chuong Ngo Peter Feiner, Angela Demke Brown, AshvinGoel University of Toronto

  2. No parents, uncles, or girlfriends were killed during the creation of this presentation The Origin Story Starting IN medias Res

  3. DBT is the Answer! • Emulation of one instruction set by another through translation of binary code during execution. • More practical than static binary translation. • Simplifies identification of executable code. • Amortization of translation overhead costs over time.

  4. …and I Remember Everything!

  5. The Answer to What? • Ports • Abandonware • Analysis • Bug finding • Security

  6. Assemble! Power Level < 9K • Pin • DynamoRio • Valgrind User Level • JIFL • PinOS

  7. All the way from Earth-1610 via Cataclysm it’s a Bird! It’s A Plane! It’s DRK!

  8. But Who Hides Behind the Mask? • 4 Goals for kernel DBT framework: • Full coverage of kernel code. • No direct overhead for user level code. • Preserve original concurrency and execution interleaving. • Be transparent. • DynamoRio for the kernel.

  9. DynamoRio Flashback! • Code cache • CTIs return control to dispatcher • Direct branching patches • Next Executing Tail • Client callbacks

  10. Well Victor…I’ve been thinking. • All kernel entry points point todispatcher. • Shadow descriptor table • Self-contained dispatcher • Custom heap allocator • “Pull” I/O model • CPU-private data • Interrupts delayed in code cache, disabled in dispatcher. • Exceptions use restored native states.

  11. A Carbonadium Skeleton

  12. DRK Initialization • Individual CPU initialization • Allocate CPU resources • All kernel entry points to dispatcher • All interrupts redirected • Allocates memory for heap • Checks all processors for successful memory mapping. • Must be within 2GB of text and data segments.

  13. DRK Normal Operations • Dispatcher creates and caches code fragment. • Context switches to the code fragment. • Determine target of control transfer instruction and dispatch. • Kernel exit points executed via native instructions.

  14. You Can’t Escape This Timeline! • Exceptions run native • Native state must be restored. • Interrupts are delayed and emulated. • Other interrupts are disabled. • Captured interrupt executed between block dispatches.

  15. How did--? This… you… What are you? How does it stack up?

  16. I’ve always found hardware to be more reliable • Test System: Dell Optiplex 980 • 8 GB RAM • 4x Intel Core i7s at 2.8 GHz, no hyperthreading • 2 Clients: • Null Client • Instruction Count • Filebench

  17. I’m the best at what I do?

  18. There’s a whole new master of magnetism in town!

  19. I know everything. I can’t help it.

  20. With great power… • 4 Goals for kernel DBT framework: • Full coverage of kernel code. • No direct overhead for user level code. • Preserve original concurrency and execution interleaving. • Be transparent.

  21. I’ll be there…around every corner • Full coverage of kernel code. • Preserve original concurrency and execution interleaving.

  22. Fastest man alive with a limp • No direct overhead for user level code. • Increased cache and TLB misses.

  23. The cosmic rays…what did they do to us? • Be transparent. • No code cache consistency. • Shadow descriptor tables readable via hardware registers. • Page table inconsistencies. • CPU-private data.

  24. …comes great responsibility. • 4 Goals for kernel DBT framework: • Full coverage of kernel code. • No direct overhead for user level code. • Preserve original concurrency and execution interleaving. • Be transparent.

  25. This was the world that I had created. DRK Applications

  26. DRK’s Shadow Memory • Storing metadata about memory used. • Ported UMBRA. • Simple indirect mapping. • Copy-on-write. • 10x overhead vs. native.

  27. KAddrcheck • Memory addressability checking tool. • Scans slab allocator’s data structures to locate all pages and freelists. • Triggers shadow memory allocations. • Addressability checks run on every memory access.

  28. Stackcheck • Checks for addressability errors. • Kills calling thread and continues. • Modified KAddrcheck • Resolves overflow without system crash. • Stack overflow guard

  29. Triumph! • DRK is a kernel-level DBT. • DynamoRIO “port”. • Heavy implementation. • Missing a number of features.

More Related