From: Masami Hiramatsu <mhiramat@kernel.org>
To: Masami Hiramatsu <mhiramat@kernel.org>
Cc: rostedt@goodmis.org,
Francis Deslauriers <francis.deslauriers@efficios.com>,
peterz@infradead.org, mathieu.desnoyers@efficios.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/3] tracing: kprobes: Prohibit probing on notrace function
Date: Sat, 28 Jul 2018 10:00:00 +0900 [thread overview]
Message-ID: <20180728100000.6861740643d5a293824d7de1@kernel.org> (raw)
In-Reply-To: <153258440707.11602.3706182300882155086.stgit@devbox>
On Thu, 26 Jul 2018 14:53:27 +0900
Masami Hiramatsu <mhiramat@kernel.org> wrote:
> Prohibit kprobe-events probing on notrace function.
> Since probing on the notrace function can cause recursive
> event call. In most case those are just skipped, but
> in some case it falls into infinit recursive call.
>
> This protection can be disabled by the kconfig
> CONFIG_KPROBE_EVENTS_ON_NOTRACE=y, but it is highly
> recommended to keep it "n" for normal kernel.
>
> Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
> Tested-by: Francis Deslauriers <francis.deslauriers@efficios.com>
> ---
> Changes from v1
> - Add CONFIG_KPROBE_EVENTS_ON_NOTRACE kconfig for knocking down
> the protection.
> ---
> kernel/trace/Kconfig | 18 ++++++++++++++++++
> kernel/trace/trace_kprobe.c | 23 +++++++++++++++++++++++
> 2 files changed, 41 insertions(+)
>
> diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
> index dcc0166d1997..24d5a58467a3 100644
> --- a/kernel/trace/Kconfig
> +++ b/kernel/trace/Kconfig
> @@ -456,6 +456,24 @@ config KPROBE_EVENTS
> This option is also required by perf-probe subcommand of perf tools.
> If you want to use perf tools, this option is strongly recommended.
>
> +config KPROBE_EVENTS_ON_NOTRACE
> + bool "Do NOT protect notrace function from kprobe events"
> + depends on KPROBE_EVENTS
> + default n
> + help
> + This is only for the developers who want to debug ftrace itself
> + using kprobe events.
> +
> + Usually, ftrace related functions are protected from kprobe-events
> + to prevent an infinit recursion or any unexpected execution path
> + which leads to a kernel crash.
> +
> + This option disables such protection and allows you to put kprobe
> + events on ftrace functions for debugging ftrace by itself.
> + Note that this might let you shoot yourself in the foot.
> +
> + If unsure, say N.
> +
> config UPROBE_EVENTS
> bool "Enable uprobes-based dynamic events"
> depends on ARCH_SUPPORTS_UPROBES
> diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
> index 27ace4513c43..1f1b4d712a7e 100644
> --- a/kernel/trace/trace_kprobe.c
> +++ b/kernel/trace/trace_kprobe.c
> @@ -496,6 +496,23 @@ disable_trace_kprobe(struct trace_kprobe *tk, struct trace_event_file *file)
> return ret;
> }
>
> +#ifdef CONFIG_KPROBE_EVENTS_ON_NOTRACE
> +#define within_notrace_func(tk) (false)
> +#else
> +static bool within_notrace_func(struct trace_kprobe *tk)
> +{
> + unsigned long offset, size, addr;
> +
> + addr = kallsyms_lookup_name(trace_kprobe_symbol(tk));
Oops, I found this is wrong. (Thanks for old myself :P)
As ftracetest probepoint.tc said, kprobe-events can be
defined without symbol (direct address) for debugging.
In that case trace_kprobe_symbol will not return the symbol string.
I'll fix this series again.
Thank you,
> + addr += trace_kprobe_offset(tk);
> +
> + if (!kallsyms_lookup_size_offset(addr, &size, &offset))
> + return true; /* Out of range. */
> +
> + return !ftrace_location_range(addr - offset, addr - offset + size);
> +}
> +#endif
> +
> /* Internal register function - just handle k*probes and flags */
> static int __register_trace_kprobe(struct trace_kprobe *tk)
> {
> @@ -504,6 +521,12 @@ static int __register_trace_kprobe(struct trace_kprobe *tk)
> if (trace_probe_is_registered(&tk->tp))
> return -EINVAL;
>
> + if (within_notrace_func(tk)) {
> + pr_warn("Could not probe notrace function %s\n",
> + trace_kprobe_symbol(tk));
> + return -EINVAL;
> + }
> +
> for (i = 0; i < tk->tp.nr_args; i++)
> traceprobe_update_arg(&tk->tp.args[i]);
>
>
--
Masami Hiramatsu <mhiramat@kernel.org>
next prev parent reply other threads:[~2018-07-28 1:00 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-26 5:52 [PATCH v2 0/3] tracing: kprobes: Prohibit probing on notrace functions Masami Hiramatsu
2018-07-26 5:53 ` [PATCH v2 1/3] tracing: kprobes: Prohibit probing on notrace function Masami Hiramatsu
2018-07-28 1:00 ` Masami Hiramatsu [this message]
2018-07-28 8:11 ` kbuild test robot
2018-07-28 13:42 ` Masami Hiramatsu
2018-07-28 8:24 ` kbuild test robot
2018-07-26 5:53 ` [PATCH v2 2/3] selftest/ftrace: Move kprobe selftest function to separate compile unit Masami Hiramatsu
2018-07-26 23:29 ` Steven Rostedt
2018-07-27 12:39 ` Masami Hiramatsu
2018-07-27 12:44 ` [PATCH v2.1 " Masami Hiramatsu
2018-07-26 5:54 ` [PATCH v2 3/3] selftests/ftrace: Fix kprobe string testcase to not probe notrace function Masami Hiramatsu
2018-07-26 7:44 ` Masami Hiramatsu
2018-07-26 19:58 ` Steven Rostedt
2018-07-26 21:22 ` Shuah Khan
2018-07-27 12:47 ` Masami Hiramatsu
2018-07-27 14:26 ` Shuah Khan
2018-07-27 14:31 ` Steven Rostedt
2018-07-28 2:24 ` Masami Hiramatsu
2018-07-27 21:43 ` Steven Rostedt
2018-07-27 23:59 ` Masami Hiramatsu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180728100000.6861740643d5a293824d7de1@kernel.org \
--to=mhiramat@kernel.org \
--cc=francis.deslauriers@efficios.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).