From: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
Sandeepa Prabhu <sandeepa.prabhu@linaro.org>,
x86@kernel.org, lkml <linux-kernel@vger.kernel.org>,
"Steven Rostedt (Red Hat)" <rostedt@goodmis.org>,
systemtap@sourceware.org, "David S. Miller" <davem@davemloft.net>
Subject: Re: Re: Re: [PATCH -tip v4 0/6] kprobes: introduce NOKPROBE_SYMBOL() and fixes crash bugs
Date: Mon, 16 Dec 2013 19:53:40 +0900 [thread overview]
Message-ID: <52AEDBB4.5060502@hitachi.com> (raw)
In-Reply-To: <52AA9C55.1000103@hitachi.com>
Hi Ingo,
(2013/12/13 14:34), Masami Hiramatsu wrote:
>>>>> And also, even if we can detect the recursion, we can't stop the
>>>>> kernel, we need to skip the probe. This means that we need to
>>>>> recover to the main execution path by doing single step. As you
>>>>> may know, since the single stepping involves the debug exception,
>>>>> we have to avoid proving on that path too. Or we'll have an
>>>>> infinite recursion again.
>>>>
>>>> I don't see why this is needed: if a "probing is disabled"
>>>> recursion flag is set the moment the first probe fires, and if
>>>> it's only cleared once all processing is finished, then any
>>>> intermediate probes should simply return early from int3 and not
>>>> fire.
>>>
>>> No, because the int3 already changes the original instruction.
>>> This means that you cannot skip singlestep(or emulate) the
>>> instruction which is copied to execution buffer (ainsn->insn),
>>> even if you have such the flag.
>>> So, kprobe requires the annotations on the singlestep path.
>>
>> I don't understand this reasoning.
>>
>> Lets assume we allow a probe to be inserted in the single-step path.
>> Such a probe will be an INT3 instruction and if it hits we get a
>> recursive INT3 invocation. In that case the INT3 handler should simply
>> restore the original instruction and _leave it so_. There's no
>> single-stepping needed - the probe is confused and must be discarded.
>
> But how can we restore the protected kernel text?
> If we use text_poke, we also need to prohibit probing on the text_poke
> and functions called in the text_poke too. That just shifts the annotated
> area to the text_poke. :(
OK, I've checked current text_poke() and thought how we can do that.
The current text_poke() uses special fixmap to make alias pages for
avoiding kernel-text readonly protection. For protecting the fixmap
pages, we are currently using text_mutex and this is why we can't use
it in exception path. There are other minor issues, but it seems to
be fixed easily. :)
Thus, for recovering original instruction in the int3 handler,
I'd like to propose adding another text_poke like function, which
requires another fixmap page and protects it by using raw_spinlock
(to avoid tracing), and just support one-byte poke (this means it
never across the page boundary).
Perhaps, it can be implemented inside kprobes, because it is not
useful for other subsystems.
Thank you!
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com
next prev parent reply other threads:[~2013-12-16 10:53 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-04 1:28 [PATCH -tip v4 0/6] kprobes: introduce NOKPROBE_SYMBOL() and fixes crash bugs Masami Hiramatsu
2013-12-04 1:28 ` [PATCH -tip v4 1/6] kprobes: Prohibit probing on .entry.text code Masami Hiramatsu
2013-12-04 1:28 ` [PATCH -tip v4 2/6] kprobes: Introduce NOKPROBE_SYMBOL() macro for blacklist Masami Hiramatsu
2013-12-04 1:28 ` [PATCH -tip v4 3/6] [BUGFIX] kprobes/x86: Prohibit probing on debug_stack_* Masami Hiramatsu
2013-12-04 1:28 ` [PATCH -tip v4 4/6] [BUGFIX] x86: Prohibit probing on native_set_debugreg Masami Hiramatsu
2013-12-04 1:28 ` [PATCH -tip v4 5/6] [BUGFIX] x86: Prohibit probing on thunk functions and restore Masami Hiramatsu
2013-12-04 1:28 ` [PATCH -tip v4 6/6] [RFC] kprobes/x86: Call exception handlers directly from do_int3/do_debug Masami Hiramatsu
2013-12-04 2:39 ` Steven Rostedt
2013-12-11 13:31 ` Jiri Kosina
2013-12-12 4:40 ` Masami Hiramatsu
2013-12-12 9:59 ` Jiri Kosina
2013-12-12 10:31 ` Masami Hiramatsu
2013-12-04 2:54 ` [PATCH -tip v4 0/6] kprobes: introduce NOKPROBE_SYMBOL() and fixes crash bugs Sandeepa Prabhu
2013-12-04 7:39 ` Masami Hiramatsu
2013-12-04 8:46 ` Sandeepa Prabhu
2013-12-04 23:32 ` Masami Hiramatsu
2013-12-04 8:45 ` Ingo Molnar
2013-12-04 23:27 ` Masami Hiramatsu
2013-12-05 10:21 ` Ingo Molnar
2013-12-06 2:34 ` Masami Hiramatsu
2013-12-10 15:28 ` Ingo Molnar
2013-12-11 2:12 ` Masami Hiramatsu
2013-12-11 13:34 ` Ingo Molnar
2013-12-12 6:02 ` Masami Hiramatsu
2013-12-12 14:03 ` Ingo Molnar
2013-12-12 20:42 ` Josh Stone
2013-12-13 5:34 ` Masami Hiramatsu
2013-12-13 6:06 ` Masami Hiramatsu
2013-12-16 10:53 ` Masami Hiramatsu [this message]
2013-12-05 13:08 ` Sandeepa Prabhu
2013-12-06 6:23 ` Masami Hiramatsu
2013-12-06 6:54 ` Sandeepa Prabhu
2013-12-06 23:25 ` Masami Hiramatsu
2013-12-05 14:49 ` Frank Ch. Eigler
2013-12-06 6:12 ` Masami Hiramatsu
2013-12-06 19:07 ` Frank Ch. Eigler
2013-12-06 23:19 ` Masami Hiramatsu
2013-12-07 1:32 ` Frank Ch. Eigler
2013-12-07 2:34 ` 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=52AEDBB4.5060502@hitachi.com \
--to=masami.hiramatsu.pt@hitachi.com \
--cc=ananth@in.ibm.com \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=rostedt@goodmis.org \
--cc=sandeepa.prabhu@linaro.org \
--cc=systemtap@sourceware.org \
--cc=x86@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.