internally-triggered attach

From bruen...@google.com 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