user kprobes vs debuggers

[Vara Prasad]

Well come to think of  this problem i am thinking this is very similar 
to the problem between Kprobes and kernel debuggers.
I am thinking we can have a common interface that ptrace and userspace 
probes can use to register break points similar to the notifiers for 
kernel probes. The common interface stores the information about all the 
break points including the ones from the ptrace interface.  There is a 
tag on the breakpoint that specifies whether the breakpoint is inserted 
by the userspace probes or ptrace. Similar to kernel multiple probe 
handlers at a probe point, we could have multiple probe handlers for 
user space probes as well. One of the probe handler among the multiple 
could be to pass it to the debugger for the probes registered by ptrace. 
When the break point is hit userspace probes gets the control and checks 
if there is a userspace probe point at this location, if yes, runs the 
userspace probes handler and if there is a ptrace registered probe point 
at the same location pass it debugger as well.  Unregistering probes of 
both types requires updating the global registery of the probe points. 

In the above discussion i didn't differentiate between /proc/pid/mem and 
ptrace() as they both go through the same interface in the kernel they 
are equivalent for this discussion.

I think this mechanism should handle applications that have breakpoints 
builtin as well because i am thinking they are going to use ptrace 
interface as well to register the breakpoint, is that correct.

Did i not consider something in the above design?

Frank Ch. Eigler wrote:

>Hi -
>
>During the teleconference earlier today, we discussed the issue of
>coexistence of user-mode kprobes (along the favoured #4 path) with
>debuggers, manipulating the same tasks.
>
>The core issue is that both systems insert breakpoints into pages
>of the target text.  Ideally, we would like both systems to operate
>independently, unaware of each other.  But:
>
>Without synchronization over "ownership" of the text pages, two
>systems may perform the insertion or removal interleaved in an
>inconvenient way.  It may be possible to lose breakpoints, or even to
>create spontaneous ones.  To perform sufficient synchronization, we
>may need to (a) detect possible conflicts after the fact, (b) bluntly
>block one system when the other is active, (c) hook user-kprobes into
>ptrace and /proc/mem code paths to intercept debuggers' operations
>and/or (d) provide a virtualization facility where the user-space
>tools only see a kprobe-less image of the real text page.
>
>A related problem is handling of breakpoints once triggered.  Clearly
>user-kprobes get to run first.  The system needs to know whether user
>space has also set a breakpoint at the same spot, so a subsequent
>ptrace signal can be propagated to the debugger.  Some peculiar
>applications may put breakpoints into themselves even without a
>debugger present, expecting to catch SIGTRAP.  Ideally, user kprobes
>should work with these too.
>
>- FChE
>
>  
>