From: Fredrik Strupe <fredrik@strupe.net>
To: Oleg Nesterov <oleg@redhat.com>,
Russell King <linux@armlinux.org.uk>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: [PATCH] arm: ptrace: Fix mask for thumb breakpoint hook
Date: Mon, 16 Mar 2020 13:12:20 +0100 [thread overview]
Message-ID: <6ab2ce75-0763-75b1-0d72-ddfb2b9dec19@strupe.net> (raw)
Since instr_mask in struct undef_hook is 32 bits wide, a mask with value
0xffff will essentially be extended to 0x0000ffff. This makes undefined
thumb2 instructions with the second half-word as 0xde01 generate SIGTRAPs
instead of SIGILLs.
This happens in total for 3143 instructions on my system. An example
of such an instruction is e800de01.
This patch fixes the issue by extending the mask to the full 32 bits,
such that both half-words have to be matched. This will remove all of
the accidental matchings, as 0x0000 is not a valid thumb2 prefix, while
preserving the intended thumb hook.
Signed-off-by: Fredrik Strupe <fredrik@strupe.net>
---
arch/arm/kernel/ptrace.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kernel/ptrace.c b/arch/arm/kernel/ptrace.c
index 36718a424..f51bec0bc 100644
--- a/arch/arm/kernel/ptrace.c
+++ b/arch/arm/kernel/ptrace.c
@@ -228,9 +228,14 @@ static struct undef_hook arm_break_hook = {
.fn = break_trap,
};
+/*
+ * Set all bits in the instruction mask, even though the thumb
+ * instruction is only 16 bits. This is to prevent accidental
+ * matching of thumb2 instructions.
+ */
static struct undef_hook thumb_break_hook = {
- .instr_mask = 0xffff,
- .instr_val = 0xde01,
+ .instr_mask = 0xffffffff,
+ .instr_val = 0x0000de01,
.cpsr_mask = PSR_T_BIT,
.cpsr_val = PSR_T_BIT,
.fn = break_trap,
--
2.20.1
reply other threads:[~2020-03-16 12:12 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=6ab2ce75-0763-75b1-0d72-ddfb2b9dec19@strupe.net \
--to=fredrik@strupe.net \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=oleg@redhat.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®