Kprobes - revision history

Dank at 03:41, 31 October 2019

2019-10-31T03:41:00Z

← Older revision		Revision as of 03:41, 31 October 2019
Line 1:		Line 1:
			[[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.		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.

Dank at 21:53, 6 October 2019

2019-10-06T21:53:00Z

← Older revision		Revision as of 21:53, 6 October 2019
Line 84:		Line 84:
	==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]]

Dank: /* Working with kprobes */

2019-10-06T06:19:09Z

Working with kprobes

← Older revision		Revision as of 06:19, 6 October 2019
Line 39:		Line 39:
	\|-		\|-
	\| 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>
	\|-		\|-

Dank: /* Working with kprobes */

2019-10-06T06:16:24Z

Working with kprobes

← Older revision		Revision as of 06:16, 6 October 2019
Line 27:		Line 27:
	\| 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>
	\|-		\|-

Dank at 06:15, 6 October 2019

2019-10-06T06:15:13Z

← Older revision		Revision as of 06:15, 6 October 2019
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~~.		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.

Dank: /* Working with kprobes */

2019-10-06T05:53:13Z

Working with kprobes

← Older revision		Revision as of 05:53, 6 October 2019
Line 37:		Line 37:
	\|\| write <tt>debug/tracing/events/kprobes/NAME/enable</tt>		\|\| write <tt>debug/tracing/events/kprobes/NAME/enable</tt>
	\|\| ?		\|\| ?
			\|-
			\| Trace kprobe
			\|\| ?
			\|\| <tt>perf trace -e kprobes:NAME</tt>
	\|-		\|-
	\|}		\|}

Dank at 05:47, 6 October 2019

2019-10-06T05:47:54Z

← Older revision		Revision as of 05:47, 6 October 2019
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.		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.		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.

	==Kernel configuration==		==Kernel configuration==

Dank: /* Working with kprobes */

2019-10-06T05:43:23Z

Working with kprobes

← Older revision		Revision as of 05:43, 6 October 2019
Line 13:		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.		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]]~~ (~~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.		The primary means for working with longterm kprobes from userspace is debugfs (typically mounted at <tt>/sys/kernel/debug</tt>) 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"		{\|class="wikitable"
	! Task !! sysfs !! perf		! Task !! sysfs !! perf
	\|-		\|-
	\| List functions suitable for probing		\| List functions suitable for probing
	\|\| read <tt>~~/sys/kernel/~~debug/tracing/available_filter_functions</tt>		\|\| read <tt>debug/tracing/available_filter_functions</tt>
	\|\| <tt>perf probe -F</tt> (note: in my experience, this always lacks a few available from the sysfs list. i'm unsure why.)		\|\| <tt>perf probe -F</tt> (note: in my experience, this always lacks a few available from the sysfs list. i'm unsure why.)
	\|-		\|-
	\| List registered kprobes		\| List registered kprobes
	\|\| read <tt>~~/sys/kernel/~~debug/kprobes/list</tt>		\|\| read <tt>debug/kprobes/list</tt>
	\|\| ?		\|\| ?
	\|-		\|-
	\| List probe events \|\| read <tt>~~/sys/kernel/~~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>~~/sys/kernel/~~debug/tracing/kprobe_events</tt>		\| Add kprobe \|\| write <tt>debug/tracing/kprobe_events</tt>
	\|\| <tt>perf probe -a</tt>		\|\| <tt>perf probe -a</tt>
	\|-		\|-
Line 35:		Line 35:
	\|-		\|-
	\| Enable kprobe		\| Enable kprobe
	\|\| write <tt>~~/sys/kernel/~~debug/tracing/events/kprobes/NAME/enable</tt>		\|\| write <tt>debug/tracing/events/kprobes/NAME/enable</tt>
	\|\| ?		\|\| ?
	\|-

	\|-		\|-
	\|}		\|}

Dank: /* Working with kprobes */

2019-10-06T05:41:49Z

Working with kprobes

← Older revision		Revision as of 05:41, 6 October 2019
Line 21:		Line 21:
	\|\| <tt>perf probe -F</tt> (note: in my experience, this always lacks a few available from the sysfs list. i'm unsure why.)		\|\| <tt>perf probe -F</tt> (note: in my experience, this always lacks a few available from the sysfs list. i'm unsure why.)
	\|-		\|-
	\| List ~~enabled~~ kprobes \|\| read <tt>/sys/kernel/debug/tracing/kprobe_events</tt> \|\| <tt>perf probe -l</tt>		\| List registered kprobes
			\|\| read <tt>/sys/kernel/debug/kprobes/list</tt>
			\|\| ?
			\|-
			\| List probe events \|\| read <tt>/sys/kernel/debug/tracing/kprobe_events</tt> \|\| <tt>perf probe -l</tt>
	\|-		\|-
	\| Add kprobe \|\| write <tt>/sys/kernel/debug/tracing/kprobe_events</tt>		\| Add kprobe \|\| write <tt>/sys/kernel/debug/tracing/kprobe_events</tt>

Dank at 05:37, 6 October 2019

2019-10-06T05:37:14Z

← Older revision		Revision as of 05:37, 6 October 2019
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==		==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.		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"		{\|class="wikitable"
	! Task !! sysfs !! perf		! Task !! sysfs !! perf