[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <161460768474.430263.18425867006584111900.stgit@devnote2>
Date: Mon, 1 Mar 2021 23:08:04 +0900
From: Masami Hiramatsu <mhiramat@...nel.org>
To: Andy Lutomirski <luto@...nel.org>, Ingo Molnar <mingo@...nel.org>
Cc: Oleg Nesterov <oleg@...hat.com>,
Masami Hiramatsu <mhiramat@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
LKML <linux-kernel@...r.kernel.org>,
Anil S Keshavamurthy <anil.s.keshavamurthy@...el.com>,
"David S . Miller" <davem@...emloft.net>, X86 ML <x86@...nel.org>,
Andrew Cooper <andrew.cooper3@...rix.com>,
Steven Rostedt <rostedt@...dmis.org>
Subject: [RFC PATCH 0/1] x86/kprobes: Remoev single-step trap from x86 kprobes
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@...nel.org>
Powered by blists - more mailing lists