* [PATCH] kprobes: bad manupilation of 2 byte opcode on x86_64
@ 2006-05-18 21:32 Satoshi Oshima
2006-05-19 8:29 ` [PATCH] kprobes: bad manipulation " Richard J Moore
0 siblings, 1 reply; 4+ messages in thread
From: Satoshi Oshima @ 2006-05-18 21:32 UTC (permalink / raw)
To: Andi Kleen, Andrew Morton
Cc: linux-kernel, systemtap, Keshavamurthy, Anil S,
Ananth N Mavinakayanahalli, Jim Keniston, Prasanna S Panchamukhi,
Hideo AOKI@redhat, Masami Hiramatsu, sugita
Hi Andi and Andrew,
I found a bug of kprobes on x86_64.
I attached the fix of this bug.
Problem:
If we put a probe onto a callq instruction and the probe
is executed, kernel panic of Bad RIP value occurs.
Root cause:
If resume_execution() found 0xff at first byte of
p->ainsn.insn, it must check the _second_ byte.
But current resume_execution check _first_ byte again.
I changed it checks second byte of p->ainsn.insn.
Kprobes on i386 don't have this problem, because
the implementation is a little bit different from
x86_64.
Regards,
Satoshi Oshima
Hitachi Computer Product (America) Inc.
----------------------------------------------
diff -Narup linux-2.6.17-rc3-mm1.orig/arch/x86_64/kernel/kprobes.c x86_64_bugifx/arch/x86_64/kernel/kprobes.c
--- linux-2.6.17-rc3-mm1.orig/arch/x86_64/kernel/kprobes.c 2006-05-04 12:34:44.000000000 -0400
+++ x86_64_bugifx/arch/x86_64/kernel/kprobes.c 2006-05-12 16:02:35.000000000 -0400
@@ -514,13 +514,13 @@ static void __kprobes resume_execution(s
*tos = orig_rip + (*tos - copy_rip);
break;
case 0xff:
- if ((*insn & 0x30) == 0x10) {
+ if ((insn[1] & 0x30) == 0x10) {
/* call absolute, indirect */
/* Fix return addr; rip is correct. */
next_rip = regs->rip;
*tos = orig_rip + (*tos - copy_rip);
- } else if (((*insn & 0x31) == 0x20) || /* jmp near, absolute indirect */
- ((*insn & 0x31) == 0x21)) { /* jmp far, absolute indirect */
+ } else if (((insn[1] & 0x31) == 0x20) || /* jmp near, absolute indirect */
+ ((insn[1] & 0x31) == 0x21)) { /* jmp far, absolute indirect */
/* rip is correct. */
next_rip = regs->rip;
}
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] kprobes: bad manipulation of 2 byte opcode on x86_64
2006-05-18 21:32 [PATCH] kprobes: bad manupilation of 2 byte opcode on x86_64 Satoshi Oshima
@ 2006-05-19 8:29 ` Richard J Moore
2006-05-19 11:33 ` Andi Kleen
0 siblings, 1 reply; 4+ messages in thread
From: Richard J Moore @ 2006-05-19 8:29 UTC (permalink / raw)
To: Satoshi Oshima
Cc: Andi Kleen, Andrew Morton, Keshavamurthy, Anil S,
Hideo AOKI@redhat, Masami Hiramatsu, Jim Keniston, linux-kernel,
Ananth N Mavinakayanahalli, Prasanna S Panchamukhi, sugita,
systemtap, systemtap-owner
Is there any possibility of a inducing a page fault when checking the
second byte?
- -
Richard J Moore
IBM Advanced Linux Response Team - Linux Technology Centre
MOBEX: 264807; Mobile (+44) (0)7739-875237
Office: (+44) (0)1962-817072
Satoshi Oshima
<soshima@redhat
.com> To
Sent by: Andi Kleen <ak@suse.de>, Andrew
systemtap-owner Morton <akpm@osdl.org>
@sourceware.org cc
linux-kernel@vger.kernel.org,
systemtap@sources.redhat.com,
18/05/2006 "Keshavamurthy, Anil S"
22:32 <anil.s.keshavamurthy@intel.com>,
Ananth N Mavinakayanahalli
<mananth@in.ibm.com>, Jim Keniston
<jkenisto@us.ibm.com>, Prasanna S
Panchamukhi <prasanna@in.ibm.com>,
"Hideo AOKI@redhat"
<haoki@redhat.com>, Masami
Hiramatsu
<hiramatu@sdl.hitachi.co.jp>,
sugita <sugita@sdl.hitachi.co.jp>
bcc
Subject
[PATCH] kprobes: bad manupilation
of 2 byte opcode on x86_64
Hi Andi and Andrew,
I found a bug of kprobes on x86_64.
I attached the fix of this bug.
Problem:
If we put a probe onto a callq instruction and the probe
is executed, kernel panic of Bad RIP value occurs.
Root cause:
If resume_execution() found 0xff at first byte of
p->ainsn.insn, it must check the _second_ byte.
But current resume_execution check _first_ byte again.
I changed it checks second byte of p->ainsn.insn.
Kprobes on i386 don't have this problem, because
the implementation is a little bit different from
x86_64.
Regards,
Satoshi Oshima
Hitachi Computer Product (America) Inc.
----------------------------------------------
diff -Narup linux-2.6.17-rc3-mm1.orig/arch/x86_64/kernel/kprobes.c
x86_64_bugifx/arch/x86_64/kernel/kprobes.c
--- linux-2.6.17-rc3-mm1.orig/arch/x86_64/kernel/kprobes.c
2006-05-04 12:34:44.000000000 -0400
+++ x86_64_bugifx/arch/x86_64/kernel/kprobes.c 2006-05-12
16:02:35.000000000 -0400
@@ -514,13 +514,13 @@ static void __kprobes resume_execution(s
*tos = orig_rip + (*tos - copy_rip);
break;
case 0xff:
- if ((*insn & 0x30) == 0x10) {
+ if ((insn[1] & 0x30) == 0x10) {
/* call absolute, indirect */
/* Fix return addr; rip is correct. */
next_rip = regs->rip;
*tos = orig_rip + (*tos - copy_rip);
- } else if (((*insn & 0x31) == 0x20) || /*
jmp near, absolute indirect */
- ((*insn & 0x31) == 0x21)) {
/* jmp far, absolute indirect */
+ } else if (((insn[1] & 0x31) == 0x20) || /*
jmp near, absolute indirect */
+ ((insn[1] & 0x31) == 0x21)) {
/* jmp far, absolute indirect */
/* rip is correct. */
next_rip = regs->rip;
}
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] kprobes: bad manipulation of 2 byte opcode on x86_64
2006-05-19 8:29 ` [PATCH] kprobes: bad manipulation " Richard J Moore
@ 2006-05-19 11:33 ` Andi Kleen
2006-05-19 14:13 ` Satoshi Oshima
0 siblings, 1 reply; 4+ messages in thread
From: Andi Kleen @ 2006-05-19 11:33 UTC (permalink / raw)
To: Richard J Moore
Cc: Satoshi Oshima, Andrew Morton, Keshavamurthy, Anil S,
Hideo AOKI@redhat, Masami Hiramatsu, Jim Keniston, linux-kernel,
Ananth N Mavinakayanahalli, Prasanna S Panchamukhi, sugita,
systemtap, systemtap-owner
On Friday 19 May 2006 10:29, Richard J Moore wrote:
> Is there any possibility of a inducing a page fault when checking the
> second byte?
AFAIK instr is in the out of line instruction copy. Kernel would need
to be pretty broken already if that page faulted.
-Andi
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] kprobes: bad manipulation of 2 byte opcode on x86_64
2006-05-19 11:33 ` Andi Kleen
@ 2006-05-19 14:13 ` Satoshi Oshima
0 siblings, 0 replies; 4+ messages in thread
From: Satoshi Oshima @ 2006-05-19 14:13 UTC (permalink / raw)
To: Andi Kleen, Richard J Moore
Cc: Andrew Morton, Keshavamurthy, Anil S, Hideo AOKI@redhat,
Masami Hiramatsu, Jim Keniston, linux-kernel,
Ananth N Mavinakayanahalli, Prasanna S Panchamukhi, sugita,
systemtap, systemtap-owner
Andi Kleen wrote:
> On Friday 19 May 2006 10:29, Richard J Moore wrote:
>> Is there any possibility of a inducing a page fault when checking the
>> second byte?
>
> AFAIK instr is in the out of line instruction copy. Kernel would need
> to be pretty broken already if that page faulted.
There is no possibility that copied instruction step over
a page boundary. Instruction slot is in the page that
is allocated in get_insn_slot(). And get_insn_slot()
acquires the page by module_alloc(), and divides into
slots.
Satoshi Oshima
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2006-05-19 14:14 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-05-18 21:32 [PATCH] kprobes: bad manupilation of 2 byte opcode on x86_64 Satoshi Oshima
2006-05-19 8:29 ` [PATCH] kprobes: bad manipulation " Richard J Moore
2006-05-19 11:33 ` Andi Kleen
2006-05-19 14:13 ` Satoshi Oshima
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox