From: Masami Hiramatsu <mhiramat@kernel.org>
To: "Eddy_Wu@trendmicro.com" <Eddy_Wu@trendmicro.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"x86@kernel.org" <x86@kernel.org>,
"David S. Miller" <davem@davemloft.net>
Subject: Re: x86/kprobes: kretprobe fails to triggered if kprobe at function entry is not optimized (trigger by int3 breakpoint)
Date: Tue, 25 Aug 2020 00:54:26 +0900 [thread overview]
Message-ID: <20200825005426.f592075d13be740cb3c9aa77@kernel.org> (raw)
In-Reply-To: <8816bdbbc55c4d2397e0b02aad2825d3@trendmicro.com>
On Mon, 24 Aug 2020 12:02:58 +0000
"Eddy_Wu@trendmicro.com" <Eddy_Wu@trendmicro.com> wrote:
> Greetings!
>
> Starting from kernel 5.8 (x86_64), kretprobe handler will always missed if corresponding kprobe on function entry is not optimized (using break point instead).
Oops, good catch. I always enabled ftrace hook for kretprobe, I didn't noticed that.
> Step to reproduce this:
> 1) Build the kretprobe example module (CONFIG_SAMPLE_KRETPROBES=m)
> 2) Disable jump optimization (`sysctl debug.kprobes-optimization=0` or register any kprobe.post_handler at same location)
> 3) Insert the kretprobe_example module
> 4) Launch some process to trigger _do_fork
> 5) Remove kretprobe_example module
> 6) dmesg shows that all probing instances are missed
>
> Example output:
> # sysctl debug.kprobes-optimization=0
> debug.kprobes-optimization = 0
> # insmod samples/kprobes/kretprobe_example.ko
> # ls > /dev/null
> # rmmod kretprobe_example
> # dmesg
> [48555.067295] Planted return probe at _do_fork: 0000000038ae0211
> [48560.229459] kretprobe at 0000000038ae0211 unregistered
> [48560.229460] Missed probing 3 instances of _do_fork
>
> After bisecting, I found this behavior seems to introduce by this commit: (5.8-rc1)
> 0d00449c7a28a1514595630735df383dec606812 x86: Replace ist_enter() with nmi_enter()
> This make kprobe_int3_handler() effectively running as NMI context, which pre_handler_kretprobe() explicitly checked to prevent recursion.
Thanks for the bisecting!
>
> (in_nmi() check appears from v3.17)
> f96f56780ca584930bb3a2769d73fd9a101bcbbe kprobes: Skip kretprobe hit in NMI context to avoid deadlock
>
> To make kretprobe work again with int3 breakpoint, I think we can replace the in_nmi() check with in_nmi() == (1 << NMI_SHIFT) at kprobe_int3_handler() and skip kretprobe if nested NMI.
Ah, I see. Now int3 is a kind of NMI, so in the handler in_nmi() always returns !0.
> Did a quick test on 5.9-rc2 and it seems to be working.
> I'm not sure if it is the best way to do since it may also require change to other architecture as well, any thought?
Hmm, this behavior is arch-dependent. So I think we need an weak function like this.
@kernel/kprobes.c
bool __weak arch_kprobe_in_nmi(void)
{
return in_nmi()
}
@arch/x86/kernel/kprobes/core.c
bool arch_kprobe_in_nmi(void)
{
/*
* Since the int3 is one of NMI, we have to check in_nmi() is
* bigger than 1 << NMI_SHIFT instead of !0.
*/
return in_nmi() > (1 << NMI_SHIFT);
}
And use arch_kprobe_in_nmi() instead of in_nmi() in kprobes.c.
Thanks,
--
Masami Hiramatsu <mhiramat@kernel.org>
next prev parent reply other threads:[~2020-08-24 15:54 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-24 12:02 x86/kprobes: kretprobe fails to triggered if kprobe at function entry is not optimized (trigger by int3 breakpoint) Eddy_Wu
2020-08-24 14:14 ` Peter Zijlstra
2020-08-24 16:18 ` Eddy_Wu
2020-08-24 18:15 ` Masami Hiramatsu
2020-08-25 7:36 ` peterz
2020-08-24 15:54 ` Masami Hiramatsu [this message]
2020-08-24 16:41 ` Eddy_Wu
2020-08-25 6:15 ` Masami Hiramatsu
2020-08-25 8:33 ` Eddy_Wu
2020-08-25 11:06 ` [PATCH] kprobes/x86: Fixes NMI context check on x86 kernel test robot
2020-08-25 12:09 ` x86/kprobes: kretprobe fails to triggered if kprobe at function entry is not optimized (trigger by int3 breakpoint) peterz
2020-08-25 13:15 ` Masami Hiramatsu
2020-08-25 13:30 ` peterz
2020-08-25 13:59 ` Masami Hiramatsu
2020-08-25 14:15 ` peterz
2020-08-25 14:10 ` peterz
2020-08-25 14:19 ` Masami Hiramatsu
2020-08-27 9:02 ` peterz
2020-08-26 7:07 ` Eddy_Wu
2020-08-26 8:22 ` Masami Hiramatsu
2020-08-26 9:06 ` Masami Hiramatsu
2020-08-26 10:00 ` Masami Hiramatsu
2020-08-26 10:25 ` peterz
2020-08-26 13:36 ` Eddy_Wu
2020-08-26 13:51 ` Masami Hiramatsu
2020-08-26 9:01 ` peterz
2020-08-26 9:21 ` peterz
2020-08-26 8:31 ` Masami Hiramatsu
2020-08-25 12:20 ` [PATCH] kprobes/x86: Fixes NMI context check on x86 kernel test robot
2020-08-25 12:25 ` kernel test robot
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=20200825005426.f592075d13be740cb3c9aa77@kernel.org \
--to=mhiramat@kernel.org \
--cc=Eddy_Wu@trendmicro.com \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.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 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).