| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <84ehg2jdny.fsf@sauna.l.org>
Date: Wed, 27 Feb 2013 11:42:41 +0200
From: Timo Juhani Lindfors <timo.lindfors@....fi>
To: linux-kernel@...r.kernel.org
Cc: Ananth N Mavinakayanahalli <ananth@...ibm.com>,
Anil S Keshavamurthy <anil.s.keshavamurthy@...el.com>,
"David S. Miller" <davem@...emloft.net>,
Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
Subject: kprobing "hash_64.constprop.26" crashes the system, recursion through get_kprobe?
There is a long-standing problem in the systemtap community where
accidentally kprobing a delicate function causes the system to crash:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604453
http://sourceware.org/bugzilla/show_bug.cgi?id=2725
https://bugzilla.redhat.com/show_bug.cgi?id=655904
http://sourceware.org/bugzilla/show_bug.cgi?id=13659
The current solution is to mark these functions with __kprobes that
places them to a separate kprobe-free section (from __kprobes_text_start
to __kprobes_text_end). This has the nice side effect that also inlined
copies of innocent functions can not be kprobed when they are called
from functions marked with __kprobes.
Now, hash_64 is marked "inline" but this is only a hint for the
compiler. On my Debian unstable system (Linux 3.7.3-1~experimental.1)
hash_64 actually exists in six different places thanks to the GCC
ipa-cp (interprocedural constant propagation) optimization:
$ grep -E "(__kprobes_text|hash_64|get_kprobe)" /boot/System.map-3.7-trunk-amd64
ffffffff810075f8 t hash_64.constprop.8
ffffffff810544a4 t hash_64
ffffffff81099908 t hash_64.constprop.26
ffffffff810b8a95 t hash_64.constprop.75
ffffffff810f70dc t hash_64.constprop.22
ffffffff811a33cc t hash_64.constprop.16
ffffffff81378538 T __kprobes_text_start
ffffffff8137c5b2 T get_kprobe
ffffffff8137d522 T __kprobes_text_end
Disassembly shows that get_kprobe calls one of these clones:
ffffffff8137c5b2 <get_kprobe>:
ffffffff8137c5b2: 53 push %rbx
ffffffff8137c5b3: 48 89 fb mov %rdi,%rbx
ffffffff8137c5b6: e8 4d d3 d1 ff callq ffffffff81099908 <hash_64.constprop.26>
ffffffff8137c5bb: 48 8b 04 c5 10 97 7b mov -0x7e8468f0(,%rax,8),%rax
ffffffff8137c5c2: 81
ffffffff8137c5c3: eb 03 jmp ffffffff8137c5c8 <get_kprobe+0x16>
ffffffff8137c5c5: 48 8b 00 mov (%rax),%rax
ffffffff8137c5c8: 48 85 c0 test %rax,%rax
ffffffff8137c5cb: 74 08 je ffffffff8137c5d5 <get_kprobe+0x23>
ffffffff8137c5cd: 48 39 58 28 cmp %rbx,0x28(%rax)
ffffffff8137c5d1: 75 f2 jne ffffffff8137c5c5 <get_kprobe+0x13>
ffffffff8137c5d3: eb 02 jmp ffffffff8137c5d7 <get_kprobe+0x25>
ffffffff8137c5d5: 31 c0 xor %eax,%eax
ffffffff8137c5d7: 5b pop %rbx
ffffffff8137c5d8: c3 retq
Trying to kprobe "hash_64.constprop.26" using
#include <linux/kprobes.h>
#include <linux/module.h>
#include <linux/ptrace.h>
static int handle_hash_64(struct kprobe *p, struct pt_regs *regs) {
return 0;
}
static struct kprobe probe_hash_64 = {
.symbol_name = "hash_64.constprop.26",
.pre_handler = handle_hash_64,
};
static int __init init_testcase1(void) {
int ret;
ret = register_kprobe(&probe_hash_64);
if (ret < 0) {
printk(KERN_WARNING "register_kprobe failed with %d\n", ret);
return -EINVAL;
}
return 0;
}
static void __exit cleanup_testcase1(void) {
unregister_kprobe(&probe_hash_64);
}
MODULE_LICENSE("GPL");
module_init(init_testcase1);
module_exit(cleanup_testcase1);
crashes the system. I used the "xm dump-core" facility of xen to dump
the memory of the domU and obtained the following bactrace using
"crash vm.img /usr/lib/debug/boot/vmlinux-3.7-trunk-amd64" and
"for bt":
PID: 3007 TASK: ffff88003b9bb840 CPU: 0 COMMAND: "insmod"
#0 [ffff88003db99998] __schedule at ffffffff813777f8
#1 [ffff88003db999a8] hash_64.constprop.26 at ffffffff81099909
#2 [ffff88003db999d0] get_kprobe at ffffffff8137c5bb
#3 [ffff88003db999e0] kprobe_exceptions_notify at ffffffff8137a3c1
#4 [ffff88003db99a40] notifier_call_chain at ffffffff8137b5a3
#5 [ffff88003db99a80] notify_die at ffffffff8137b60c
#6 [ffff88003db99ab0] do_int3 at ffffffff81378fa0
#7 [ffff88003db99ad0] xen_int3 at ffffffff8137887e
[exception RIP: hash_64.constprop.26+1]
RIP: ffffffff81099909 RSP: ffff88003db99b80 RFLAGS: 00000086
RAX: 0000000000000000 RBX: ffffffff81099908 RCX: 00000000ffffffff
RDX: ffff88003db99c38 RSI: 0000000000000002 RDI: ffffffff81099908
RBP: 0000000000000002 R8: 0000000000000000 R9: ffffffff81629b10
R10: 00000000000066a8 R11: ffffffffa016a000 R12: ffff88003f80dd90
R13: ffffffff81099908 R14: ffffffff81099909 R15: ffffffffa016a010
ORIG_RAX: ffffffffffffffff CS: 10000e030 SS: e02b
#8 [ffff88003db99b80] get_kprobe at ffffffff8137c5bb
#9 [ffff88003db99b90] kprobe_exceptions_notify at ffffffff8137a3c1
#10 [ffff88003db99bf0] notifier_call_chain at ffffffff8137b5a3
#11 [ffff88003db99c30] notify_die at ffffffff8137b60c
#12 [ffff88003db99c60] do_int3 at ffffffff81378fa0
#13 [ffff88003db99c80] xen_int3 at ffffffff8137887e
[exception RIP: hash_64.constprop.26+1]
RIP: ffffffff81099909 RSP: ffff88003db99d30 RFLAGS: 00000246
RAX: 0000000000000000 RBX: ffffffff81099908 RCX: ffffffffa0000521
RDX: ffffffff81099908 RSI: ffffffff81099908 RDI: ffffffff81099908
RBP: ffff88003db99e10 R8: 000000000000140b R9: ffffffff81099908
R10: 00000000000066a8 R11: ffffffffa016a000 R12: ffffffff81099908
R13: ffffffff81099903 R14: 0000000000000000 R15: ffffffffa016a010
ORIG_RAX: ffffffffffffffff CS: e030 SS: e02b
#14 [ffff88003db99d30] get_kprobe at ffffffff8137c5bb
#15 [ffff88003db99d40] __recover_optprobed_insn at ffffffff8102d4d4
#16 [ffff88003db99d70] recover_probed_instruction at ffffffff8102d479
#17 [ffff88003db99d90] can_optimize at ffffffff8137a952
#18 [ffff88003db99e50] arch_prepare_optimized_kprobe at ffffffff8137ab2c
#19 [ffff88003db99ea0] alloc_aggr_kprobe.isra.17 at ffffffff8137bb9b
#20 [ffff88003db99ec0] register_kprobe at ffffffff8137cf16
#21 [ffff88003db99f00] init_module at ffffffffa000600d [testcase1]
#22 [ffff88003db99f10] do_one_initcall at ffffffff810020b6
#23 [ffff88003db99f40] sys_init_module at ffffffff81083c4f
#24 [ffff88003db99f80] system_call_fastpath at ffffffff8137d6e9
RIP: 00007f4aef62414a RSP: 00007fffbd2e9d08 RFLAGS: 00000202
RAX: 00000000000000af RBX: ffffffff8137d6e9 RCX: 00007f4aef62048a
RDX: 00007f4aef8e3f68 RSI: 000000000002b833 RDI: 00007f4aefcca000
RBP: 00007f4af0a391a0 R8: 0000000000000003 R9: 0000000000000000
R10: 00007f4aef62048a R11: 0000000000000202 R12: 00007f4aef8e3f68
R13: 00007f4af0a39270 R14: 00007f4af0a38090 R15: 0000000000000000
ORIG_RAX: 00000000000000af CS: e033 SS: e02b
It seems that the recursion occurs even before register_kprobe
returns. I am not sure how this should be solved. Should we mark hash_64
with __kprobes? Or perhaps with __attribute__((always_inline))?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists