Kprobes

Line 1:

Kprobes use the breakpoint mechanism to dynamically instrument Linux kernel code. Two types exist: kprobes can be attached to all but a few blacklisted instruction ranges in a running kernel, while kretprobes are attached to a function and run when it returns. This instrumentation ~~is typically~~ packaged as a kernel module or [[~~eBPF~~]].

Kprobes use the breakpoint mechanism to dynamically instrument Linux kernel code. Two types exist: kprobes can be attached to all but a few blacklisted instruction ranges in a running kernel, while kretprobes 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.

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, but they are specified by kernel authors, as opposed to dynamic kprobes.

==Kernel configuration==

Line 11:

Line 13:

To add, trace, and destroy a kprobe, use the <tt>kprobe</tt> binary (sometimes known as <tt>kprobe-perf</tt>) from the [[perf]] toolkit.

The primary means for working with longterm kprobes from userspace is [[sysfs]] and the [[perf]] tool. Note that <tt>/sys/kernel/debug/tracing/events/kprobes</tt> will not appear until you have enabled at least one kprobe.

The primary means for working with longterm kprobes from userspace is [[sysfs]] (technically debugfs) and the [[perf]] tool. Note that <tt>/sys/kernel/debug/tracing/events/kprobes</tt> will not appear until you have enabled at least one kprobe.

{|class="wikitable"

! Task !! sysfs !! perf

Kprobes: Difference between revisions

Dank (talk | contribs)

@@ 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 is typically packaged as a kernel module or [[eBPF]].
+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.
+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, but they are specified by kernel authors, as opposed to dynamic kprobes.
 ==Kernel configuration==
@@ Line 11: / Line 13: @@
 To add, trace, and destroy a kprobe, use the <tt>kprobe</tt> binary (sometimes known as <tt>kprobe-perf</tt>) from the [[perf]] toolkit.
-The primary means for working with longterm kprobes from userspace is [[sysfs]] and the [[perf]] tool. Note that <tt>/sys/kernel/debug/tracing/events/kprobes</tt> will not appear until you have enabled at least one kprobe.
+The primary means for working with longterm kprobes from userspace is [[sysfs]] (technically debugfs) and the [[perf]] tool. Note that <tt>/sys/kernel/debug/tracing/events/kprobes</tt> will not appear until you have enabled at least one kprobe.
 {|class="wikitable"
 ! Task !! sysfs !! perf