From: Peter Zijlstra <peterz@infradead.org>
To: mhiramat@kernel.org
Cc: Borislav Petkov <bp@alien8.de>,
linux-kernel@vger.kernel.org, Ingo Molnar <mingo@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>
Subject: kprobes vs __ex_table[]
Date: Thu, 23 Feb 2017 19:30:02 +0100 [thread overview]
Message-ID: <20170223183002.GD6557@twins.programming.kicks-ass.net> (raw)
Hi Masami,
I just wondered what would happen if I put a probe on an instruction
that was listed in __ex_table[] or __bug_table[].
And it looks like it will happily do that. It will then run the
instruction out-of-line, and when said instruction traps, the
instruction address will not match the one listed in either __ex_table[]
or __bug_table[] and badness will happen.
If kprobes does indeed not check this, we should probably fix it, if it
does do check this, could you point me to it?
next reply other threads:[~2017-02-23 18:30 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-23 18:30 Peter Zijlstra [this message]
2017-02-24 1:04 ` kprobes vs __ex_table[] Masami Hiramatsu
2017-02-24 9:26 ` Peter Zijlstra
2017-02-24 16:34 ` Masami Hiramatsu
2017-02-24 17:48 ` Peter Zijlstra
2017-02-27 16:12 ` [RFC PATCH 0/2] kprobes/x86: Handle probing on ex_table cases Masami Hiramatsu
2017-02-27 16:13 ` [RFC PATCH 1/2] kprobes/x86: Use probe_kernel_read instead of memcpy Masami Hiramatsu
2017-02-27 16:14 ` [RFC PATCH 2/2] kprobes/x86: Exit single-stepping before trying fixup_exception Masami Hiramatsu
2017-03-01 23:30 ` Masami Hiramatsu
2017-02-28 16:16 ` kprobes vs __ex_table[] Masami Hiramatsu
2017-02-28 16:23 ` [PATCH] [BUGFIX] kprobes/x86: Fix to check __ex_table entry by probed address Masami Hiramatsu
2017-03-01 9:13 ` [tip:perf/urgent] kprobes/x86: Fix kernel panic when certain exception-handling addresses are probed tip-bot for 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=20170223183002.GD6557@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=bp@alien8.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=mingo@kernel.org \
--cc=tglx@linutronix.de \
/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