From: wangnan0@huawei.com (Wang Nan)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4] kprobes: arm: enable OPTPROBES for ARM 32
Date: Tue, 12 Aug 2014 21:03:02 +0800 [thread overview]
Message-ID: <53EA1086.4010606@huawei.com> (raw)
In-Reply-To: <1407819388-52145-1-git-send-email-wangnan0@huawei.com>
Hi Masami and everyone,
When checking my code I found a problem: if we replace a stack operatinon instruction,
it is possible that the emulate execution of such instruction destroy the stack used
by kprobeopt:
> +
> +asm (
> + ".global optprobe_template_entry\n"
> + "optprobe_template_entry:\n"
> + " sub sp, sp, #80\n"
> + " stmia sp, {r0 - r14} \n"
Here, trampoline code sub sp with 80 (0x50, I choose this number without much thinking), and then
use stmia to push r0 - r14 (registers except pc) onto the stack. Assume the original sp is
0xd0000050, the stack becomes:
0xd0000000: r0
0xd0000004: r1
0xd0000008: r2
...
0xd0000038: r14
0xd000003c: r15 (place holder)
0xd0000040: cpsr (place holder)
0xd0000044: ?
0xd0000048: ?
0xd000004c: ?
0xd0000050: original stack
If the replaced code operates stack, for example, push {r0 - r10}, it will overwrite our register.
For that reason, sub sp, #80 is not enough, we need at least 64 bytes stack space, so the first instruction
here should be sub sp, #128.
However, it increase stack requirement. Moreover, although rare, there may be sp relative addressing,
such as: str r1, [sp, #-132].
To make every situations safe, do you think we need to alloc a pre-cpu optprobe private stack?
For example:
str sp, [pc, #??] (store original sp first)
ldr sp, [pc, #??] (load pre-cpu stack)
sub sp, #68
stmia sp, {r0 - r12}
... (fix sp and pc in stack)
ldmia sp, {r0 - r15}
optprobe_template_sp:
1: .long 0 (placeholder for saved sp)
optprobe_template_private_stack:
2: .long 0 (placeholder for per-cpu private stack)
optprobe_template_pc:
3: .long 0 (placeholder for pc)
> + " add r3, sp, #80\n"
> + " str r3, [sp, #52]\n"
> + " mrs r4, cpsr\n"
> + " str r4, [sp, #64]\n"
> + " mov r1, sp\n"
> + " ldr r0, 1f\n"
> + " ldr r2, 2f\n"
> + " blx r2\n"
> + " ldr r1, [sp, #64]\n"
> + " msr cpsr_fs, r1\n"
> + " ldmia sp, {r0 - r15}\n"
> + ".global optprobe_template_val\n"
> + "optprobe_template_val:\n"
> + "1: .long 0\n"
> + ".global optprobe_template_call\n"
> + "optprobe_template_call:\n"
> + "2: .long 0\n"
> + ".global optprobe_template_end\n"
> + "optprobe_template_end:\n");
> +
WARNING: multiple messages have this Message-ID (diff)
From: Wang Nan <wangnan0@huawei.com>
To: Wang Nan <wangnan0@huawei.com>,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
"Jon Medhurst (Tixy)" <tixy@linaro.org>, <ananth@in.ibm.com>,
<anil.s.keshavamurthy@intel.com>, <davem@davemloft.net>,
Will Deacon <will.deacon@arm.com>,
<linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>
Cc: <peifeiyue@huawei.com>, <lizefan@huawei.com>
Subject: Re: [PATCH v4] kprobes: arm: enable OPTPROBES for ARM 32
Date: Tue, 12 Aug 2014 21:03:02 +0800 [thread overview]
Message-ID: <53EA1086.4010606@huawei.com> (raw)
In-Reply-To: <1407819388-52145-1-git-send-email-wangnan0@huawei.com>
Hi Masami and everyone,
When checking my code I found a problem: if we replace a stack operatinon instruction,
it is possible that the emulate execution of such instruction destroy the stack used
by kprobeopt:
> +
> +asm (
> + ".global optprobe_template_entry\n"
> + "optprobe_template_entry:\n"
> + " sub sp, sp, #80\n"
> + " stmia sp, {r0 - r14} \n"
Here, trampoline code sub sp with 80 (0x50, I choose this number without much thinking), and then
use stmia to push r0 - r14 (registers except pc) onto the stack. Assume the original sp is
0xd0000050, the stack becomes:
0xd0000000: r0
0xd0000004: r1
0xd0000008: r2
...
0xd0000038: r14
0xd000003c: r15 (place holder)
0xd0000040: cpsr (place holder)
0xd0000044: ?
0xd0000048: ?
0xd000004c: ?
0xd0000050: original stack
If the replaced code operates stack, for example, push {r0 - r10}, it will overwrite our register.
For that reason, sub sp, #80 is not enough, we need at least 64 bytes stack space, so the first instruction
here should be sub sp, #128.
However, it increase stack requirement. Moreover, although rare, there may be sp relative addressing,
such as: str r1, [sp, #-132].
To make every situations safe, do you think we need to alloc a pre-cpu optprobe private stack?
For example:
str sp, [pc, #??] (store original sp first)
ldr sp, [pc, #??] (load pre-cpu stack)
sub sp, #68
stmia sp, {r0 - r12}
... (fix sp and pc in stack)
ldmia sp, {r0 - r15}
optprobe_template_sp:
1: .long 0 (placeholder for saved sp)
optprobe_template_private_stack:
2: .long 0 (placeholder for per-cpu private stack)
optprobe_template_pc:
3: .long 0 (placeholder for pc)
> + " add r3, sp, #80\n"
> + " str r3, [sp, #52]\n"
> + " mrs r4, cpsr\n"
> + " str r4, [sp, #64]\n"
> + " mov r1, sp\n"
> + " ldr r0, 1f\n"
> + " ldr r2, 2f\n"
> + " blx r2\n"
> + " ldr r1, [sp, #64]\n"
> + " msr cpsr_fs, r1\n"
> + " ldmia sp, {r0 - r15}\n"
> + ".global optprobe_template_val\n"
> + "optprobe_template_val:\n"
> + "1: .long 0\n"
> + ".global optprobe_template_call\n"
> + "optprobe_template_call:\n"
> + "2: .long 0\n"
> + ".global optprobe_template_end\n"
> + "optprobe_template_end:\n");
> +
next prev parent reply other threads:[~2014-08-12 13:03 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-12 4:56 [PATCH v4] kprobes: arm: enable OPTPROBES for ARM 32 Wang Nan
2014-08-12 4:56 ` Wang Nan
2014-08-12 13:03 ` Wang Nan [this message]
2014-08-12 13:03 ` Wang Nan
2014-08-12 15:12 ` Masami Hiramatsu
2014-08-12 15:12 ` Masami Hiramatsu
2014-08-15 15:23 ` Masami Hiramatsu
2014-08-15 15:23 ` Masami Hiramatsu
2014-08-16 1:38 ` Wang Nan
2014-08-16 1:38 ` Wang Nan
2014-08-16 2:44 ` Masami Hiramatsu
2014-08-16 2:44 ` Masami Hiramatsu
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=53EA1086.4010606@huawei.com \
--to=wangnan0@huawei.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.