From: Masami Hiramatsu <mhiramat@kernel.org>
To: Andy Lutomirski <luto@kernel.org>, Ingo Molnar <mingo@kernel.org>
Cc: Oleg Nesterov <oleg@redhat.com>,
Masami Hiramatsu <mhiramat@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
LKML <linux-kernel@vger.kernel.org>,
Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>,
"David S . Miller" <davem@davemloft.net>, X86 ML <x86@kernel.org>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Steven Rostedt <rostedt@goodmis.org>
Subject: [RFC PATCH 0/1] x86/kprobes: Remoev single-step trap from x86 kprobes
Date: Mon, 1 Mar 2021 23:08:04 +0900 [thread overview]
Message-ID: <161460768474.430263.18425867006584111900.stgit@devnote2> (raw)
In-Reply-To: <20210225112245.607c70ec13cf8d279390e89e@kernel.org>
Hi Andy,
Here is the patch to remove the single-step debug trap from the x86 kprobe.
This uses int3 as you suggested instead of the debug trap, for removing the
iret which returns to kernel.
Some instructions must be emulated and some instructions becomes not able
to be probed, but as far as I can see those are not rare case.
TODOs/discussions
- extend kprobe debugfs interface to show the arch-dependent flags, like
[BOOST], [EMULATE].
- Consider this emulation code split into a file and share it with uprobe
(uprobe already has its own emulator) and alternatives (it has int3_emulate_*)
but it can be overengineering.
- Add testcases for emulator. Current kprobe smoke test is not arch specific.
Maybe better to probe an assembly target code so that it can test "boosted",
"emulated" or "int3-single-stepped" cases.
Thank you,
---
Masami Hiramatsu (1):
x86/kprobes: Use int3 instead of debug trap for single-step
arch/x86/include/asm/kprobes.h | 21 +-
arch/x86/kernel/kprobes/core.c | 515 ++++++++++++++++++++++++++--------------
arch/x86/kernel/traps.c | 3
3 files changed, 351 insertions(+), 188 deletions(-)
--
Masami Hiramatsu (Linaro) <mhiramat@kernel.org>
next prev parent reply other threads:[~2021-03-01 14:10 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-23 23:24 Why do kprobes and uprobes singlestep? Andy Lutomirski
2021-02-24 1:17 ` Masami Hiramatsu
2021-02-24 19:45 ` Andy Lutomirski
2021-02-25 2:22 ` Masami Hiramatsu
2021-02-25 6:03 ` Andy Lutomirski
2021-02-25 9:11 ` Masami Hiramatsu
2021-03-01 14:08 ` Masami Hiramatsu [this message]
2021-03-01 14:08 ` [RFC PATCH 1/1] x86/kprobes: Use int3 instead of debug trap for single-step Masami Hiramatsu
2021-03-02 8:06 ` Peter Zijlstra
2021-03-02 8:38 ` Peter Zijlstra
2021-03-02 8:41 ` Peter Zijlstra
2021-03-02 8:54 ` Peter Zijlstra
2021-03-02 12:51 ` Masami Hiramatsu
2021-03-02 13:58 ` Peter Zijlstra
2021-03-02 15:25 ` [PATCH -tip 0/3] x86/kprobes: Remoev single-step trap from x86 kprobes Masami Hiramatsu
2021-03-02 15:25 ` [PATCH -tip 1/3] x86/kprobes: Retrieve correct opcode for group instruction Masami Hiramatsu
2021-03-23 15:15 ` [tip: x86/core] " tip-bot2 for Masami Hiramatsu
2021-03-02 15:25 ` [PATCH -tip 2/3] x86/kprobes: Identify far indirect JMP correctly Masami Hiramatsu
2021-03-23 15:15 ` [tip: x86/core] " tip-bot2 for Masami Hiramatsu
2021-03-02 15:25 ` [PATCH -tip 3/3] x86/kprobes: Use int3 instead of debug trap for single-step Masami Hiramatsu
2021-03-23 15:15 ` [tip: x86/core] " tip-bot2 for Masami Hiramatsu
2021-03-17 14:55 ` [PATCH -tip 0/3] x86/kprobes: Remoev single-step trap from x86 kprobes Masami Hiramatsu
2021-03-17 16:26 ` Peter Zijlstra
2021-03-17 17:45 ` Andy Lutomirski
2021-02-25 9:59 ` Why do kprobes and uprobes singlestep? Peter Zijlstra
2021-03-01 16:51 ` Oleg Nesterov
2021-03-02 1:36 ` Andy Lutomirski
2021-03-02 20:24 ` Alexei Starovoitov
2021-03-02 21:02 ` Andy Lutomirski
2021-03-03 1:22 ` Alexei Starovoitov
2021-03-03 1:46 ` Andy Lutomirski
2021-03-03 2:18 ` Alexei Starovoitov
2021-03-03 13:27 ` Oleg Nesterov
2021-03-03 18:11 ` Daniel Xu
2021-03-03 19:14 ` Andy Lutomirski
2021-03-02 20:25 ` Oleg Nesterov
2021-03-02 20:35 ` Andy Lutomirski
2021-03-02 20:28 ` Oleg Nesterov
2021-03-02 2:22 ` Masami Hiramatsu
2021-03-02 2:48 ` Andy Lutomirski
2021-03-02 20:31 ` Oleg Nesterov
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=161460768474.430263.18425867006584111900.stgit@devnote2 \
--to=mhiramat@kernel.org \
--cc=andrew.cooper3@citrix.com \
--cc=anil.s.keshavamurthy@intel.com \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@kernel.org \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.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).