for -early injection, handle app overlapping with libdynamorio.so

[derekbruening]

From bruen...@google.com on July 24, 2013 15:15:24

Xref issue #630 which got a little muddled with other reachability issues so
I'm opening a new issue. Xref issue #774 which solved all reachability issues
other than those with early injection.

DR's early injection init should be fixed to not map the app on top of
itself (today it passes MAP_FIXED and can clobber itself, resulting in
mysterious crashes). As a first step it should just bail there.

As a second step, if the app PIE we should just map it somewhere else.

To properly fix for non-PIE: the frontend does an exec, so it has little
control. Some ideas:

1. We build two different instances of libdynamorio.so: one with a low
   preferred addr, and one with a high. The front-end picks based on
   which doesn't overlap with the app.

2. The front-end is unchanged. DR maps a new DR in a different place when
   it realizes there's a conflict.

3. Instead of exec-ing libdynamorio.so, we exec an interpreter script or
   sthg which checks where to load DR.

4. The front-end creates a private copy of libdynamorio.so and changes its
   preferred base by hacking the binary.

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

[derekbruening]

From bruen...@google.com on July 24, 2013 16:00:46

xref issue #1004

[derekbruening]

From peter.goodman on July 29, 2013 08:54:27

Here is my attempt to understand each approach, please let me know if I'm way off!

1. In this case, does the front-end inspect the ELF headers of the app
   and decide based on that?

   PIE Case: in privload_early_inject, check if e_type is ET_DYN [1], and
   pass in false (not fixed) to elf_loader_map_phdrs.

   Non-PIE Case: in fork_suspend_child, before execv, check the ELF
   headers for argv[0](app executable), and if it's not dynamic
   (ET_DYN) then change real_exe (libdynamorio.so) to be something like
   (libdynamorio_high.so).

2. Can you describe how this might work? Is it something like mmap
   libdynamorio.so to a new location, dump any global state about
   the current vmareas of DR (e.g. pretend DR doesn't exist where it
   currently is), and then JMP to the entrypoint of the newly mmaped
   libdynamorio.so, wherein that will unmap the old one and then
   go through the normal early loading procedure as usual?

3. Is this a mix of (1) and (2)? For example, set the preferred base
   of this interpreter script to really high to avoid conflicts, then
   bring in the app, then bring in dynamorio somewhere that doesn't
   conflict with the app, then jmp to the entrypoint of dynamorio? Or,
   find where the app will want to go, bring in DR in a non-conflicting
   spot, and jmp to an unchanged DR entrypoint that then brings in the
   app.

4. When do you see this happening? Would this be something like a similar
   interpreter script to (3), or in the injector itself?

[1] Is this sufficient for detecting PIEs?

[derekbruening]

From bruen...@google.com on August 01, 2013 11:55:23

1. PIE can be handled separately: we should just map it somewhere it doesn't overlap (see "second step" in OP). The idea for non-PIE here is to look in the ELF file, find the base, and if it overlaps with DR then pick the "other" DR.

2. Yes, though this is early enough that DR hasn't fully initialized itself so there shouldn't be any vmareas interaction.

3. This could be just like 2) but with a bootstrapper that is more easily unmapped such that it doesn't matter if it conflicts w/ the app.

4. In drinjectlib.