From: Peter Zijlstra <peterz@infradead.org>
To: Masami Hiramatsu <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: Re: kprobes vs __ex_table[]
Date: Fri, 24 Feb 2017 10:26:46 +0100 [thread overview]
Message-ID: <20170224092646.GL6515@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <20170224100451.31ca3855ddb36963b93d0768@kernel.org>
On Fri, Feb 24, 2017 at 10:04:51AM +0900, Masami Hiramatsu wrote:
> On Thu, 23 Feb 2017 19:30:02 +0100
> Peter Zijlstra <peterz@infradead.org> wrote:
>
> > 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[].
>
> Ah, thanks for reporting, I know __ex_table issue and fixed, but
> I didn't care about __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.
>
> For the __ex_table[], at least on x86, kprobes already handles it in
> kprobe_fault_handler, which restore regs->ip to original place when
> a pagefault happens on singlestepping.
Ah, but that is only #PF, we also use __ex_table on other faults/traps,
like #GP which would need help in do_general_protection(), and I have a
patch (that might not ever go anywhere) that uses it on #UD (but for all
I know we already use #UD to probe existence of instructions).
In any case, we call fixup_exception() from pretty much all exception
vectors, not only #PF.
But see below.
> > If kprobes does indeed not check this, we should probably fix it, if it
> > does do check this, could you point me to it?
>
> Yeah, for BUG() case, as far as I can see, there is no check about that.
So I've a patch that extends __bug_table[] to WARN (like many other
architectures already have).
http://lkml.kernel.org/r/20170223132813.GB6515@twins.programming.kicks-ass.net
> So, there are 2 ways to fix it up, one is to just reject to put kprobes on
> UD2, another is fixup trap address as we did for exceptions_table.
> I think latter is better because if there is a divide error happening
> on single-step, anyway we should fixup the address...
Right.
So I like the fixup idea, just not sure the current
kprobe_fault_handler() is sufficient or correct.
It looks like it rewrites regs->ip, which would make return from fault
return to the wrong place, no?
Would it not be better to do the fixup in fixup_exception()/fixup_bug()?
Because then we cover all callers, not just #PF.
One more complication with __ex_table and optimized kprobes is that we
need to be careful not to clobber __ex_table[].fixup. It would be very
bad if the optimized probe were to clobber the address we let the fixup
return to -- or that needs fixups too, _after_ running
__ex_table[].handler().
next prev parent reply other threads:[~2017-02-24 9:27 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-23 18:30 kprobes vs __ex_table[] Peter Zijlstra
2017-02-24 1:04 ` Masami Hiramatsu
2017-02-24 9:26 ` Peter Zijlstra [this message]
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=20170224092646.GL6515@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 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.