All of lore.kernel.org
 help / color / mirror / Atom feed
From: Masami Hiramatsu <mhiramat@kernel.org>
To: Ingo Molnar <mingo@redhat.com>
Cc: Masami Hiramatsu <mhiramat@kernel.org>,
	peterz@infradead.org,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Andrea Righi <righi.andrea@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	stable@vger.kernel.org
Subject: [PATCH 5/9] kprobes: Search non-suffixed symbol in blacklist
Date: Thu, 10 Jan 2019 11:56:24 +0900	[thread overview]
Message-ID: <154708898461.6325.17046972809561067053.stgit@devbox> (raw)
In-Reply-To: <154708884117.6325.4454464467156828009.stgit@devbox>

Newer gcc can generate some different instances of a function
with suffixed symbols if the function is optimized and only
has a part of that. (e.g. .constprop, .part etc.)

In this case, it is not enough to check the entry of kprobe
blacklist because it only records non-suffixed symbol address.

To fix this issue, search non-suffixed symbol in blacklist if
given address is within a symbol which has a suffix.

Note that this can cause false positive cases if a kprobe-safe
function is optimized to suffixed instance and has same name
symbol which is blacklisted.
But I would like to chose a fail-safe design for this issue.

Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
---
 kernel/kprobes.c |   21 ++++++++++++++++++++-
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index e8c76164f541..faa519f07aad 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -1396,7 +1396,7 @@ bool __weak arch_within_kprobe_blacklist(unsigned long addr)
 	       addr < (unsigned long)__kprobes_text_end;
 }
 
-bool within_kprobe_blacklist(unsigned long addr)
+static bool __within_kprobe_blacklist(unsigned long addr)
 {
 	struct kprobe_blacklist_entry *ent;
 
@@ -1410,7 +1410,26 @@ bool within_kprobe_blacklist(unsigned long addr)
 		if (addr >= ent->start_addr && addr < ent->end_addr)
 			return true;
 	}
+	return false;
+}
 
+bool within_kprobe_blacklist(unsigned long addr)
+{
+	char symname[KSYM_NAME_LEN], *p;
+
+	if (__within_kprobe_blacklist(addr))
+		return true;
+
+	/* Check if the address is on a suffixed-symbol */
+	if (!lookup_symbol_name(addr, symname)) {
+		p = strchr(symname, '.');
+		if (!p)
+			return false;
+		*p = '\0';
+		addr = (unsigned long)kprobe_lookup_name(symname, 0);
+		if (addr)
+			return __within_kprobe_blacklist(addr);
+	}
 	return false;
 }
 


  parent reply	other threads:[~2019-01-10  2:56 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-10  2:54 [PATCH 0/9] kprobes: Fix and improve blacklist symbols Masami Hiramatsu
2019-01-10  2:54 ` [PATCH 1/9] x86/kprobes: Prohibit probing on optprobe template code Masami Hiramatsu
2019-01-10  6:07   ` Greg KH
2019-01-10 14:57     ` Masami Hiramatsu
2019-01-10 17:10       ` Steven Rostedt
2019-01-11  0:52         ` Masami Hiramatsu
2019-01-10  2:54 ` [PATCH 2/9] x86/kprobes: Move trampoline code into RODATA Masami Hiramatsu
2019-01-10  2:55 ` [PATCH 3/9] x86/kprobes: Prohibit probing on functions before kprobe_int3_handler() Masami Hiramatsu
2019-01-10  2:55 ` [PATCH 4/9] x86/kprobes: Prohibit probing on IRQ handlers directly Masami Hiramatsu
2019-01-10  2:56 ` Masami Hiramatsu [this message]
2019-01-10  2:56 ` [PATCH 6/9] kprobes: Prohibit probing on hardirq tracers Masami Hiramatsu
2019-01-10 17:12   ` Steven Rostedt
2019-01-11 14:21     ` Masami Hiramatsu
2019-01-10  2:57 ` [PATCH 7/9] kprobes: Prohibit probing on preempt_check debug functions Masami Hiramatsu
2019-01-10  2:57 ` [PATCH 8/9] kprobes: Prohibit probing on RCU debug routine Masami Hiramatsu
2019-01-10  2:58 ` [PATCH 9/9] kprobes: Prohibit probing on lockdep functions 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=154708898461.6325.17046972809561067053.stgit@devbox \
    --to=mhiramat@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=righi.andrea@gmail.com \
    --cc=rostedt@goodmis.org \
    --cc=stable@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.