• Jiri Kosina's avatar
    kprobes/x86: Call out into INT3 handler directly instead of using notifier · 17f41571
    Jiri Kosina authored
    In fd4363ff ("x86: Introduce int3 (breakpoint)-based
    instruction patching"), the mechanism that was introduced for
    notifying alternatives code from int3 exception handler that and
    exception occured was die_notifier.
    
    This is however problematic, as early code might be using jump
    labels even before the notifier registration has been performed,
    which will then lead to an oops due to unhandled exception. One
    of such occurences has been encountered by Fengguang:
    
     int3: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
     Modules linked in:
     CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.11.0-rc1-01429-g04bf576 #8
     task: ffff88000da1b040 ti: ffff88000da1c000 task.ti: ffff88000da1c000
     RIP: 0010:[<ffffffff811098cc>]  [<ffffffff811098cc>] ttwu_do_wakeup+0x28/0x225
     RSP: 0000:ffff88000dd03f10  EFLAGS: 00000006
     RAX: 0000000000000000 RBX: ffff88000dd12940 RCX: ffffffff81769c40
     RDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000001
     RBP: ffff88000dd03f28 R08: ffffffff8176a8c0 R09: 0000000000000002
     R10: ffffffff810ff484 R11: ffff88000dd129e8 R12: ffff88000dbc90c0
     R13: ffff88000dbc90c0 R14: ffff88000da1dfd8 R15: ffff88000da1dfd8
     FS:  0000000000000000(0000) GS:ffff88000dd00000(0000) knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
     CR2: 00000000ffffffff CR3: 0000000001c88000 CR4: 00000000000006e0
     Stack:
      ffff88000dd12940 ffff88000dbc90c0 ffff88000da1dfd8 ffff88000dd03f48
      ffffffff81109e2b ffff88000dd12940 0000000000000000 ffff88000dd03f68
      ffffffff81109e9e 0000000000000000 0000000000012940 ffff88000dd03f98
     Call Trace:
      <IRQ>
      [<ffffffff81109e2b>] ttwu_do_activate.constprop.56+0x6d/0x79
      [<ffffffff81109e9e>] sched_ttwu_pending+0x67/0x84
      [<ffffffff8110c845>] scheduler_ipi+0x15a/0x2b0
      [<ffffffff8104dfb4>] smp_reschedule_interrupt+0x38/0x41
      [<ffffffff8173bf5d>] reschedule_interrupt+0x6d/0x80
      <EOI>
      [<ffffffff810ff484>] ? __atomic_notifier_call_chain+0x5/0xc1
      [<ffffffff8105cc30>] ? native_safe_halt+0xd/0x16
      [<ffffffff81015f10>] default_idle+0x147/0x282
      [<ffffffff81017026>] arch_cpu_idle+0x3d/0x5d
      [<ffffffff81127d6a>] cpu_idle_loop+0x46d/0x5db
      [<ffffffff81127f5c>] cpu_startup_entry+0x84/0x84
      [<ffffffff8104f4f8>] start_secondary+0x3c8/0x3d5
      [...]
    
    Fix this by directly calling poke_int3_handler() from the int3
    exception handler (analogically to what ftrace has been doing
    already), instead of relying on notifier, registration of which
    might not have yet been finalized by the time of the first trap.
    Reported-and-tested-by: default avatarFengguang Wu <fengguang.wu@intel.com>
    Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
    Acked-by: default avatarMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
    Cc: H. Peter Anvin <hpa@linux.intel.com>
    Cc: Fengguang Wu <fengguang.wu@intel.com>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Link: http://lkml.kernel.org/r/alpine.LNX.2.00.1307231007490.14024@pobox.suse.czSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
    17f41571
alternative.h 8.05 KB