add events for Windows APC, NtContinue, callback, and cbret

[derekbruening]

From derek.br...@gmail.com on December 11, 2009 21:39:16

This was PR 200410

NtContinue and NtCallbackReturn can be watched for via the syscall events, and int 0x2b via the bb event. The Ki entries can be monitored via the bb event as well. So this would be a purely convenience set of events. The callback start and stop events can be important when keeping thread-shared state, because often some part of the state should be shared across callbacks while other parts should be separated.

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

[derekbruening]

From bruen...@google.com on August 28, 2011 14:01:59

drmgr's "callback-local storage" (CLS) from issue #402 solves the state sharing problem

[derekbruening]

I'm adding a "kernel transfer" event which includes these Ki events, syscalls that change context, the signal delivery from #1693, and sigreturn.

There are many complications. I will try to summarize them:

• Some event types only have an OS context (sigcontext or CONTEXT) and it is not worth copying it into a dr_mcontext_t if the user doesn't care about anything but the pc. So I decided to pass in the prior pc (if known), the new pc, and the new xsp (used in DrM and other shadow mem tools), and have the client call dr_get_mcontext() if it really wants more. I added new "os_cxt_ptr_t" types and support for this.

• There don't seem to be many uses cases for changing the context: for signals we already have DR_SIGNAL_REDIRECT; changing Ki dispatchers seems unlikely to happen; we can't do it for cbret; for Windows syscalls there are complications with the app only setting some of the ContextFlags. But it's not hard to have minimal support for it so I'm putting it in.

• Continuing the ContextFlags issue: on query it's there as well, xbp in CONTEXT_CONTROL yet in DR_MC_INTEGER. I documented the issue: up to clients. They should pass both CONTROL and INTEGER if they want xbp, and it is rare to see an app select only one or the other.

• I decided to raise this event on dr_redirect_execution() and DR_SIGNAL_REDIRECT too.

• I added logic to pass the real Ki pc and not the hook-displaced pc.

• I don't think it's possible to pass the real xsi and not the syscall return address for a cbret.

• It is not easy to get a full source context so I'm only giving the pc, when it's known.

[derekbruening]

These and #1693 can be used to simplify Dr. Memory, which today looks for the Ki entry points and monitors syscalls to get this information for updating shadow state.

[derekbruening]

Dr. Memory's use case needs the source xsp for sigreturn handling. But if we provide a full source context for syscalls, doesn't it seem weird to then require dr_get_mcontext for the full target context?

Breaking down by event type:

• sig deliver cache: src sc_orig untranslated, tgt sc
• sig deliver dispatch: src dc->mc, tgt dc->mc
• sigreturn: src dc->mc, tgt sc
• APC dispatcher: src CONTEXT, tgt state->mc
• callback dispatcher: no src, tgt state->mc
• exception dispatcher: src CONTEXT, tgt state->mc
• raise dispatcher: no src, tgt state->mc
• NtContinue: src dc->mc, tgt CONTEXT
• NtSetContextThread: src dc->mc, tgt CONTEXT
• NtCallbackReturn: src dc->mc, tgt dc->mc BUT some regs not there like xsi
• int 0x2b: src dc->mc, tgt dc->mc BUT some regs not there like xsi
• dr_redirect_execution: no src (if from fault; have src for clean call), tgt dmc
• DR_SIGNAL_REDIRECT: src dc->mc, tgt sc

I guess the biggest perf worry should be timer signals and Windows callbacks. Timer signals should always be from dispatch, but we need to copy mc to a dmc before setting up for the handler, and then copy the handler's mc to a dmc: so two large copies if we have to include simd state.

We could only include CONTROL and INTEGER for the src: simd should be identical in every case to the tgt. So for efficiency, we'd pass in a source dr_mcontext_t CONTROL+INTEGER, and just the target pc+xsp, and require dr_get_mcontext() for the target??

[derekbruening]

Getting the source context for some of these end up requiring extra work but it's worth it in the end as some use cases need it. For dr_redirect_execution we can call dr_get_mcontext() if we take one extra step and point at the exception context in cur_mc so it will work for both clean calls and exception events.