1 / 14

(Static) binary rewriting: where do we go?

(Static) binary rewriting: where do we go?. Bjorn De Sutter. Overview. Our old work Context changes New opportunities. Our old work (1). Dynamic Binary Rewriting tool called Diota good for instrumentation vertical profiling (JVM for example). Our old work (2). Static binary rewriting

anitra
Download Presentation

(Static) binary rewriting: where do we go?

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. (Static) binary rewriting: where do we go? Bjorn De Sutter

  2. Overview • Our old work • Context changes • New opportunities

  3. Our old work (1) • Dynamic Binary Rewriting • tool called Diota • good for instrumentation • vertical profiling (JVM for example)

  4. Our old work (2) • Static binary rewriting • long history • first link-time rewriting prototypes on Alpha • Alto: program optimization • Squeeze: program compaction • Squeeze++: C++ oriente program compaction • retargertable, extensible link-time rewriting framework • Diablo

  5. Our old work (3) • Diablo applications • program compaction and program optimization • ARM and x86 • great results on top of GCC and ARM RVCT • kernel specialization (Linux) • system call optimization • boot process optimization • compaction • in kernel page fault support • cold code compression

  6. Our old work (4) • Diablo applications • program instrumentation • ATOM-like tool called FIT for ARM and x86 • software protection • obfuscation techniques • steganography • diversity

  7. Context changes (1) • Improved compilers and libraries

  8. Context changes (2) • Compilers with whole-program optimization • ARM a.c armcc a.o b.c armcc b.o optimizing ld + feedback a.out c.c armcc c.o

  9. Context changes (3) • Compilers with whole-program optimization • Google and GCC a.c gcc a.o + gimple gcc a.o + gimple a.o + gimple b.c gcc b. o + gimple WPO gcc b. o + gimple b. o + gimple c.c gcc c. o + gimple gcc c. o + gimple c. o + gimple includes summary information contains results of WPO

  10. Context changes (4) • Process variability • processors (and components) used to work as designed • is no longer true • large variation on performance leaving the fab • a lot of defects leaving the fab • a lot in memories, since memories take a lot of area

  11. New Opportunities (1) • Large parts of whole-program optimization is done in the compiler. • What remains to be done for the binary rewriter? • Is interesting research question, but there are also practical applications.

  12. New Opportunities (2) • customization of binaries • diversity • software protection in general • cannot be done during compilation because it takes too much time • updating and patching of software requires install-time rewriting • load-time applications? • optimizations based on known addresses?

  13. New Opportunities (3) • Dealing with defects in processors • some systems will not have run-time code generation • implants • wireless sensors • still need to shrink the transistors because of power consumption limitations and temperature • so many devices will have defects

  14. New Opportunities (4) • adapt software to defects at install time or at run time • not full rewriting • more a kind of fine-grained relocation capabilities

More Related