kprobes/powerpc: Fix possible system crash during out-of-line single-stepping
PATCH 1/1 kprobes/powerpc: Fix possible system crash during out-of-line single-stepping
- On archs that have no-exec support, we vmalloc() a executable scratch area of PAGE_SIZE and divide it up into an array of slots of maximum instruction size for that arch
- On a kprobe registration, the original instruction is copied to the first available free slot, so if multiple kprobes are registered, chances are, they get contiguous slots
- On POWER4, due to not having coherent icaches, we could hit a situation where a probe that is registered on one processor, is hit immediately on another. This second processor could have fetched the stream of text from the out-of-line single-stepping area *before* the probe registration completed, possibly due to an earlier (and a different) kprobe hit and hence would see stale data at the slot.
Executing such an arbitrary instruction lead to a problem as reported in LTC bugzilla 23555.
The correct solution is to call flush_icache_range() as soon as the instruction is copied for out-of-line single-stepping, so the correct instruction is seen on all processors.
Thanks to Will Schmidt who tracked this down.
Ananth
---
--- arch/powerpc/kernel/kprobes.c | 2 ++ 1 files changed, 2 insertions(+)
arch/powerpc/kernel/kprobes.c +2 -0
@@ -61,6 +61,8 @@ int __kprobes arch_prepare_kprobe(structif (!ret) {memcpy (p->ainsn.insn, p->addr,MAX_INSN_SIZE *sizeof (kprobe_opcode_t)); p->opcode = *p->addr; +flush_icache_range ((unsigned long )p->ainsn.insn, + (unsigned long )p->ainsn.insn +sizeof (kprobe_opcode_t)); }return ret;
Quoted 20 lines · Ananth N Mavinakayanahalli
- On archs that have no-exec support, we
vmalloc()a executable scratch area ofPAGE_SIZEand divide it up into an array of slots of maximum instruction size for that arch
- On a kprobe registration, the original instruction is copied to the first available free slot, so if multiple kprobes are registered, chances are, they get contiguous slots
- On POWER4, due to not having coherent icaches, we could hit a situation where a probe that is registered on one processor, is hit immediately on another. This second processor could have fetched the stream of text from the out-of-line single-stepping area *before* the probe registration completed, possibly due to an earlier (and a different) kprobe hit and hence would see stale data at the slot.Executing such an arbitrary instruction lead to a problem as reported in LTC bugzilla 23555.
The correct solution is to call
flush_icache_range()as soon as the instruction is copied for out-of-line single-stepping, so the correct instruction is seen on all processors.
Quoted 6 lines
Thanks to Will Schmidt who tracked this down.
Ananth
---Signed-off-by Ananth N Mavinakayanahalli <[email protected]>
-Will