derek.bruening/2009/i157-private-loader-Windows.diff

[derekbruening]

From [email protected] on November 26, 2009 00:58:15

issue #157: private Windows loader for safe system library use by DR and clients

This is a pretty big Windows-specific feature and I know you're not as
familiar with Windows so this is an optional review: spend as little or as
much time critiquing as you like. Most likely there will be more features
that need to be added later as this evolves so unless I hear an objection I
may commit this soon and incorporate review suggestions into later commits.

This commit adds a fairly complete loader:

• locates by searching first client paths and then system paths
• loads and relocates
• processes imports
• handles forwarded exports
• calls entry points for process and thread attach and detach
• ref count and ordered list for proper unloading
• redirect Rtl*Heap, but for now only the core alloc/free routines

Testing:

• enabled stl_test on windows, tested on calc
• tested kjrupnow's extended stl_test test on calc
• tested use of dbghelp.dll for online symbol lookup, which brings in
  5 dependent libraries

There are some improvements and features I'm not supporting for now which I
filed as separate Issues. I don't expect these to be a problem for initial
use, and we may never need these, but just in case I put the use of the
private loader under an on-by-default runtime option -private_loader so the
regular loader can be used if desired.

issue #235: redirect more of ntdll for more transparent private libraries:

• in particular, redirect Ldr*
• we'll redirect any additional routines as transparency issues come up

issue #233: advanced private Windows loader features:

• import by ordinal
• delay-load dlls
• bound imports
• import hint
• TLS (though expect only in .exe not .dll)

issue #232: nested try/except:

• then we can check readability of everything more easily: today
  not checking everything in the name of performance

This loader completely solves on Windows:

issue #30: support clients using standard libraries: STL in particular

This loader is a step toward:

issue #234: earliest Windows injection:

• use bootstrap loader w/ manual syscalls or ntdll binding to load DR
  itself with this private loader at very first APC point
  issue symbol table lookup support for clients #44: symbol table lookup support for clients
• just need to add a platform-independent API and add link support for
  dbghelp.dll along with documentation on where to get it

stats: 2115 diff lines
api/samples/CMakeLists.txt | 8
core/CMakeLists.txt | 1
core/heap.c | 19
core/heap.h | 5
core/linux/os.c | 6
core/optionsx.h | 6
core/os_shared.h | 4
core/perscache.c | 19
core/utils.h | 8
core/vmareas.c | 9
core/win32/aslr.c | 2
core/win32/loader.c | 1020 ++++++++++++++++++++++++++++++++++++++++++
core/win32/module.c | 76 +!
core/win32/module_shared.c | 29 !
core/win32/os.c | 49 !
core/win32/os_exports.h | 6
core/win32/os_private.h | 12
core/x86/instrument.c | 1
make/DynamoRIOConfig.cmake.in | 12
19 files changed, 1116 insertions(+), 10 deletions(-), 166 modifications(!)

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

[derekbruening]

From [email protected] on December 04, 2009 15:57:58

The loader_init is called in os_init.
However the os_init is called after instrument_load_client_libs in
dynamorio_app_init, which means loader_init is called after client library are
actually loaded.

[derekbruening]

From [email protected] on December 04, 2009 16:14:52

This is by design. In order to set up the x64 reachability constraints and determine
where the heap will be, we need to know where the client libs are. Yet we can't
fully initialize until the heap is set up. So we map the client libs in very early,
and then later do full initialization. I believe there are comments explaining this
in instrument.c, loader.c, and dynamo.c.

[derekbruening]

From [email protected] on December 21, 2009 13:46:14

In privload_map_and_relocate() comment at line 634, why do you allows other
private-loaded libs to be on the DR-areas list? Should all library loaded by private
loader are client libs and their dependencies?

[derekbruening]

From [email protected] on January 03, 2010 18:20:43

As part of isolated privately-loaded libs I want them to NOT be considered to contain
valid application code: I want to fault if the app tries to execute from them. I'm
using the DR areas list for that. And logically they are part of DR and not part of
the app. However, I could see adding a feature that allows a client to load a
library privately but consider it part of the app: that would require some flag or
something. If you have such a use case file a new issue for it.

[derekbruening]

From [email protected] on April 20, 2010 11:24:15

Status: Verified