internally-triggered attach

[derekbruening]

From [email protected] on April 07, 2012 17:31:16

xref issue #38 : attach injection on Linux

this issue covers attaching to the process based on an intra-process
trigger. this trigger is code under our control, probably something like a call to the start/stop API (with perhaps a mechanism to make it work when we're not there which may be good to have for the start/stop API in
general: tofile separately and xref annotations though many variants of
those assume we're already in control)

the initial use case for this type of attaching is to avoid start-up
overhead and only start using the code cache after all the general app
initialization, for large apps.

on windows, the attach mechanism will likely not look very different for
an intra- vs extra-process trigger. on linux, however, due to the lack of
IPC API's, a separate mechanism is needed.

my proposal is for the code we control that is already in the process and
that hits the trigger to register a handler for its thread group, enumerate threads via /proc, and send each thread a signal to take it over.

this assumes that:

• CLONE_SIGHAND is set for all threads (required by CLONE_THREAD anyway)
• there's only one thread group in the process
• the signal we use is not masked (or pending, if not using RT signal) in
  any thread

the core linux attach issue of determining CLONE_* sharing is identical for internal and external triggers

on Windows, we could require that the trigger is not inside any callback
stack, and just live w/ other threads in callbacks losing control until
their next syscall hook (like we already do w/ AppInit injection), though
it's much worse when there are multiple threads running around.
may need back-decode heuristics or kernel support: or try to identify but
not find prior cxt when in cb and wait during initial attach round.

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

[derekbruening]

From [email protected] on April 09, 2012 11:59:17

xref issue #725 : attach feature on Windows

[derekbruening]

From [email protected] on April 24, 2012 11:37:18

As per our discussion, I'm looking into this.

At first, I considered creating some kind of lightweight injector library that the app can link against or dlopen and have that bring in DynamoRIO however we want it to, but I think that's too wildly different from our current deployment schemes.

Instead, I think we should keep doing what we're doing on all platforms, namely keep using drrun and DrMemory's injection-based frontend. All we do is add a runtime option that disables the full app take over. This is pretty much identical to any probe mode we'd create, so I'd just call this option -probe_mode.

Then, the app uses the start/stop API to call dynamorio_app_take_over. I hacked this in on Linux with env vars to disable take over in libdrpreload.so and put dlsym(RTLD_DEFAULT, "dynamorio_app_take_over") into Chrome's unit test support, and it seems to work, barring some things we know about: misses a pre-existing thread and our signal handlers conflict with the app.

The speed up for starting up unit_tests (all builds, probably not representative) is dramatic!

take over at preload:
real 1m1.355s
user 0m27.830s
sys 0m33.290s

take over at ChromeTestSuite::Initialize:
real 0m1.415s
user 0m0.780s
sys 0m0.590s

Long term, does dlsym seem like a good way to detect DynamoRIO and trigger an internal attach if present? The nice thing about it is that it Just Works without plumbing a flag or env var into Chrome, it just relies on our presence in the loader. OTOH we've just been talking about how to isolate ourselves from the loader, which would break this dlsym approach. IMO if we ever implement full loader isolation, we can preload some other library that exports the take over symbol and knows how to all up into DR.

I plan to focus on Linux first, but does this general approach sound good on Windows? IIUC we currently remove ourselves from the list of loaded modules unless -no_hide is passed. If so, the app can do GetModuleHandle("dynamorio.dll");GetProcAddress(hmod, "dynamorio_app_take_over").

Owner: [email protected]

[ghost]

Derek,

Will this work to externally attach to running apps without modification or setting LD_PRELOAD and which have explicit dlopen calls? Would be great to test in Linux, but don't see documentation around this runtime option -- possible I missed it, I'm a new user.

Thanks,

[derekbruening]

This issue is about attaching with the cooperation of the app, so no it won't attach to an unmodified app: you want issues #37 and #38. IIRC we've finished most of the major core pieces needed to implement proper attach, so if you would like to try to finish it off we would welcome the contribution.

[derekbruening]

This internally-triggered Linux attach was pretty much finished a while back so I'm closing it.

Any problems should be filed as separate issues, such as #2016, #2018.