private loader for safe system library use by DR and clients

From derek.br...@gmail.com on June 06, 2009 16:39:03

private loader that isolates private copy of libraries for use by DR and client has many advantages:

• can have DR and client use same libc
• have entire, modern, distro-appropriate libc at disposal
• transparent
• do same thing on Windows and Linux on Windows, 2nd copy of kernel32 calls into single system ntdll copy
• lets us inject earlier
• can use for more than just libc:
  • libstdc++
  • symbol resolution using libelf/libdwarf in-process
  • other utility libs: anything "well-behaved" that can handle 2nd copy

the main alternative of static libc is problematic:

• difficult to find all-BSD-license libc
• mini-libc (just string routines) both hard to isolate and not sufficient for clients
• requiring users to build static PIC libc on their own from distro's sources too onerous
• want libstdc++, libelf, etc. as well

challenges of private loader:

• system calls
  • on Windows, we can redirect the dup kernel32's calls to ntdll to go through DR instead
  • on Linux, could redirect list of libc syscall wrappers to DR. for other embedded syscalls: leave it up to user to ensure not using lib routine that calls syscall that trips up DR?
• libraries that have global assumptions: absolute addresses, IPC, etc. we just won't support those

would solve: issue #30 (closed)/PR 200203: support for standard libraries issue #46 (closed)/PR 206369: libc independence PR 352425: [linux] transparency: hide from dl_iterate_phdr() issue #44 (closed)/PR 243532: [API] symbol table lookup support

should enable: issue #47 (closed)/PR 204554: early injection on linux PR 204587: earliest injection

still problematic: issue #36: GLIBC_2.7 from sscanf !HAVE_PROC_MAPS uses dl_iterate_phdr: but have alternative of VSI (PR 398083)

Original issue: http://code.google.com/p/dynamorio/issues/detail?id=157