From: Li Huafei <lihuafei1@huawei.com>
To: <stable@vger.kernel.org>
Cc: <gregkh@linuxfoundation.org>, <mhiramat@kernel.org>,
<tglx@linutronix.de>, <mingo@redhat.com>, <bp@alien8.de>,
<x86@kernel.org>, <hpa@zytor.com>, <sashal@kernel.org>,
<peterz@infradead.org>, <linux-kernel@vger.kernel.org>,
<xukuohai@huawei.com>, <natechancellor@gmail.com>,
<ndesaulniers@google.com>, <rostedt@goodmis.org>,
<weiyongjun1@huawei.com>, <gustavoars@kernel.org>,
<namit@vmware.com>, <laijs@linux.alibaba.com>,
<clang-built-linux@googlegroups.com>, <lihuafei1@huawei.com>
Subject: [PATCH 5.10 0/9] x86/kprobes: Fix kprobe debug exception handling logic
Date: Wed, 5 Jul 2023 14:46:44 +0800 [thread overview]
Message-ID: <20230705064653.226811-1-lihuafei1@huawei.com> (raw)
We found an issue with null pointer access due to kprobe debug exception
error handling on 5.10, and I proposed a separate fix patch for 5.10,
see [1]. But as Greg gave advice, we always choose to backport relevant
patches from upstream to fix issues with stable kernels, so I made this
patch set.
The main one we need to backport is patch 5, which uses int3 instead of
debug trap for single-stepping, thus avoiding the problems we
encountered with kprobe debug exception error handling. Patches 1-4 are
pre-patches, and patches 6-9 are fixes for patch 5. The major
modifications are patch 2 and patch 5. Patch 2 optimizes
resume_execution() to avoid repeated instruction decoding, and patch 5
uses int3 instead of debug trap, and as Masami said in the commit
message this patch will change some behavior of kprobe, but it has
almost no effect on the actual usage.
Please let me know if there are any problems, thanks!
[1] https://lore.kernel.org/lkml/20230630020845.227939-1-lihuafei1@huawei.com/
Gustavo A. R. Silva (1):
kprobes/x86: Fix fall-through warnings for Clang
Masami Hiramatsu (5):
x86/kprobes: Do not decode opcode in resume_execution()
x86/kprobes: Retrieve correct opcode for group instruction
x86/kprobes: Identify far indirect JMP correctly
x86/kprobes: Use int3 instead of debug trap for single-step
x86/kprobes: Fix to identify indirect jmp and others using range case
Masami Hiramatsu (Google) (1):
x86/kprobes: Update kcb status flag after singlestepping
Nadav Amit (1):
x86/kprobes: Fix JNG/JNLE emulation
Wei Yongjun (1):
x86/kprobes: Move 'inline' to the beginning of the kprobe_is_ss()
declaration
arch/x86/include/asm/kprobes.h | 24 +-
arch/x86/kernel/kprobes/core.c | 639 ++++++++++++++++++++-------------
arch/x86/kernel/traps.c | 3 -
3 files changed, 409 insertions(+), 257 deletions(-)
--
2.17.1
next reply other threads:[~2023-07-05 6:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-05 6:46 Li Huafei [this message]
2023-07-05 6:46 ` [PATCH 5.10 1/9] kprobes/x86: Fix fall-through warnings for Clang Li Huafei
2023-07-05 6:46 ` [PATCH 5.10 2/9] x86/kprobes: Do not decode opcode in resume_execution() Li Huafei
2023-07-05 6:46 ` [PATCH 5.10 3/9] x86/kprobes: Retrieve correct opcode for group instruction Li Huafei
2023-07-05 6:46 ` [PATCH 5.10 4/9] x86/kprobes: Identify far indirect JMP correctly Li Huafei
2023-07-05 6:46 ` [PATCH 5.10 5/9] x86/kprobes: Use int3 instead of debug trap for single-step Li Huafei
2023-07-05 6:46 ` [PATCH 5.10 6/9] x86/kprobes: Fix to identify indirect jmp and others using range case Li Huafei
2023-07-05 6:46 ` [PATCH 5.10 7/9] x86/kprobes: Move 'inline' to the beginning of the kprobe_is_ss() declaration Li Huafei
2023-07-05 6:46 ` [PATCH 5.10 8/9] x86/kprobes: Update kcb status flag after singlestepping Li Huafei
2023-07-05 6:46 ` [PATCH 5.10 9/9] x86/kprobes: Fix JNG/JNLE emulation Li Huafei
2023-08-04 9:57 ` [PATCH 5.10 0/9] x86/kprobes: Fix kprobe debug exception handling logic Greg KH
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=20230705064653.226811-1-lihuafei1@huawei.com \
--to=lihuafei1@huawei.com \
--cc=bp@alien8.de \
--cc=clang-built-linux@googlegroups.com \
--cc=gregkh@linuxfoundation.org \
--cc=gustavoars@kernel.org \
--cc=hpa@zytor.com \
--cc=laijs@linux.alibaba.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=mingo@redhat.com \
--cc=namit@vmware.com \
--cc=natechancellor@gmail.com \
--cc=ndesaulniers@google.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=sashal@kernel.org \
--cc=stable@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=weiyongjun1@huawei.com \
--cc=x86@kernel.org \
--cc=xukuohai@huawei.com \
/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
all inboxes | Powered by JetHome®