Kprobes: Difference between revisions

No edit summary
 
(4 intermediate revisions by the same user not shown)
Line 1: Line 1:
Kprobes use the breakpoint mechanism to dynamically instrument Linux kernel code. Two types exist: <i>kprobes</i> can be attached to all but a few blacklisted instruction ranges in a running kernel, while <i>kretprobes</i> are attached to a function and run when it returns. This instrumentation can be packaged as a kernel module (using the <tt>register_probe</tt> and <tt>unregister_probe</tt> kernel API), implemented as a <tt>BPF_PROG_TYPE_KPROBE</tt>-type [[eBPF]] program, or configured via debugfs or the [[perf]] tool.
[[File:Osseu-commonality.png|thumb|right|Linux tracing systems]]
 
Kprobes use the breakpoint mechanism to dynamically instrument Linux kernel code. Two types exist: <i>kprobes</i> can be attached to all but a few blacklisted instruction ranges in a running kernel, while <i>kretprobes</i> are attached to a function and run when it returns. This instrumentation can be packaged as a kernel module (using the <tt>register_probe</tt> and <tt>unregister_probe</tt> kernel API, as done by SystemTap), manipulated via debugfs (as done by ftrace), configured using the [[perf]] tool, or implemented as a <tt>BPF_PROG_TYPE_KPROBE</tt>-type [[eBPF]] program.


uprobes are the userspace equivalent of kprobes. jprobes are no longer a thing. i don't believe dprobes to be a thing anymore, either, but might be mistaken. tracepoints are places to hook the same kind of analysis, explicitly specified by kernel authors using <tt>TRACE_EVENT</tt>; think of them as "opt-in", as opposed to dynamic kprobes, though there is a tracepoint for each system call.
uprobes are the userspace equivalent of kprobes. jprobes are no longer a thing. i don't believe dprobes to be a thing anymore, either, but might be mistaken. tracepoints are places to hook the same kind of analysis, explicitly specified by kernel authors using <tt>TRACE_EVENT</tt>; think of them as "opt-in", as opposed to dynamic kprobes, though there is a tracepoint for each system call.
Line 27: Line 29:
| List probe events || read <tt>debug/tracing/kprobe_events</tt> || <tt>perf probe -l</tt>
| List probe events || read <tt>debug/tracing/kprobe_events</tt> || <tt>perf probe -l</tt>
|-
|-
| Add kprobe || write <tt>debug/tracing/kprobe_events</tt>
| Add kprobe || write def to <tt>debug/tracing/kprobe_events</tt>
|| <tt>perf probe -a</tt>
|| <tt>perf probe -a</tt> def
|-
|-
| Remove kprobe
| Remove kprobe
|| ?
|| write <tt>-:NAME</tt> to <tt>debug/tracing/kprobe_events</tt>
|| <tt>perf probe -d</tt>
|| <tt>perf probe -d</tt>
|-
|-
Line 39: Line 41:
|-
|-
| Trace kprobe
| Trace kprobe
|| ?
|| read <tt>debug/tracing/trace_pipe</tt>
|| <tt>perf trace -e kprobes:NAME</tt>
|| <tt>perf trace -e kprobes:NAME</tt>
|-
|-
Line 84: Line 86:
==Further reading==
==Further reading==
* LWN's [https://lwn.net/Articles/132196/ Introduction to Kprobes], 2005-04-18
* LWN's [https://lwn.net/Articles/132196/ Introduction to Kprobes], 2005-04-18
==See also==
* [[perf]]
* [[eBPF]]