From: Dave.Martin@arm.com (Dave Martin)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/4] ARM: kprobes: fix instruction fetch order with <asm/opcodes.h>
Date: Fri, 2 Aug 2013 15:03:22 +0100 [thread overview]
Message-ID: <20130802140322.GB2361@localhost.localdomain> (raw)
In-Reply-To: <51F968CB.8060605@codethink.co.uk>
On Wed, Jul 31, 2013 at 08:43:07PM +0100, Ben Dooks wrote:
> On 29/07/13 09:01, Jon Medhurst (Tixy) wrote:
> >On Thu, 2013-07-25 at 22:08 +0100, Ben Dooks wrote:
> >>If we are running BE8, the data and instruction endian-ness do not
> >>match, so use<asm/opcodes.h> to correctly translate memory accesses
> >>into ARM instructions.
> >>
> >>Signed-off-by: Ben Dooks<ben.dooks@codethink.co.uk>y
> >>---
> >> arch/arm/kernel/kprobes-common.c | 14 ++++++++------
> >> arch/arm/kernel/kprobes.c | 9 +++++----
> >> 2 files changed, 13 insertions(+), 10 deletions(-)
> >>
> >>diff --git a/arch/arm/kernel/kprobes-common.c b/arch/arm/kernel/kprobes-common.c
> >>index 18a7628..c0b202e 100644
> >>--- a/arch/arm/kernel/kprobes-common.c
> >>+++ b/arch/arm/kernel/kprobes-common.c
> >>@@ -14,6 +14,7 @@
> >> #include<linux/kernel.h>
> >> #include<linux/kprobes.h>
> >> #include<asm/system_info.h>
> >>+#include<asm/opcodes.h>
> >>
> >> #include "kprobes.h"
> >>
> >>@@ -305,7 +306,8 @@ kprobe_decode_ldmstm(kprobe_opcode_t insn, struct arch_specific_insn *asi)
> >>
> >> if (handler) {
> >> /* We can emulate the instruction in (possibly) modified form */
> >>- asi->insn[0] = (insn& 0xfff00000) | (rn<< 16) | reglist;
> >>+ asi->insn[0] = __opcode_to_mem_arm((insn& 0xfff00000) |
> >>+ (rn<< 16) | reglist);
> >> asi->insn_handler = handler;
> >> return INSN_GOOD;
> >> }
> >>@@ -338,9 +340,9 @@ prepare_emulated_insn(kprobe_opcode_t insn, struct arch_specific_insn *asi,
> >> thumb_insn[2] = 0x4770; /* Thumb bx lr */
> >
> >The line above and the one before it not in this diff also need fixing
> >by changing to __opcode_to_mem_thumb16(0x4770).
>
> IIRC, these are then fixed by the set_emulated instruction, which is
> also why the insn return is not swapped.
Ah, I see.
I think it would be better to have consistent behaviour between the ARM
and Thumb cases here: in its current form, this patch makes
set_emulated_insn() responsible for the swabbing in the Thumb case and
not in the ARM case.
Doing it in the same place for both cases would be preferable ... or was
there a reason why this doesn't work?
Cheers
---Dave
> >> return insn;
> >> }
> >>- asi->insn[1] = 0xe12fff1e; /* ARM bx lr */
> >>+ asi->insn[1] = __opcode_to_mem_arm(0xe12fff1e); /* ARM bx lr */
> >> #else
> >>- asi->insn[1] = 0xe1a0f00e; /* mov pc, lr */
> >>+ asi->insn[1] = __opcode_to_mem_arm(0xe1a0f00e); /* mov pc, lr */
> >> #endif
> >> /* Make an ARM instruction unconditional */
> >> if (insn< 0xe0000000)
> >>@@ -360,12 +362,12 @@ set_emulated_insn(kprobe_opcode_t insn, struct arch_specific_insn *asi,
> >> if (thumb) {
> >> u16 *ip = (u16 *)asi->insn;
> >> if (is_wide_instruction(insn))
> >>- *ip++ = insn>> 16;
> >>- *ip++ = insn;
> >>+ *ip++ = ___asm_opcode_to_mem_thumb16(insn>> 16);
> >>+ *ip++ = ___asm_opcode_to_mem_thumb16(insn);
> >
[...]
next prev parent reply other threads:[~2013-08-02 14:03 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-25 21:08 fyi - kprobes testing patches Ben Dooks
2013-07-25 21:08 ` [PATCH 1/4] ARM: kprobes: fix instruction fetch order with <asm/opcodes.h> Ben Dooks
2013-07-29 8:01 ` Jon Medhurst (Tixy)
2013-07-31 19:43 ` Ben Dooks
2013-08-02 13:57 ` Dave Martin
2013-08-02 13:58 ` Ben Dooks
2013-08-02 14:03 ` Dave Martin [this message]
2013-07-25 21:08 ` [PATCH 2/4] ARM: kprobes, change arm test to .instr Ben Dooks
2013-07-25 21:08 ` [PATCH 3/4] ARM: kprobes-test: use <asm/opcodes.h> Ben Dooks
2013-07-29 8:07 ` Jon Medhurst (Tixy)
2013-07-31 19:38 ` Ben Dooks
2013-07-25 21:08 ` [PATCH 4/4] ARM: kprobes-test: move to using a pointer to the title text Ben Dooks
2013-07-26 14:02 ` Dave Martin
2013-07-26 14:08 ` Ben Dooks
2013-07-26 10:52 ` fyi - kprobes testing patches Ben Dooks
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=20130802140322.GB2361@localhost.localdomain \
--to=dave.martin@arm.com \
--cc=linux-arm-kernel@lists.infradead.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