1. 21 6月, 2018 5 次提交
  2. 14 5月, 2018 1 次提交
    • M
      kprobes/x86: Prohibit probing on exception masking instructions · ee6a7354
      Masami Hiramatsu 提交于
      Since MOV SS and POP SS instructions will delay the exceptions until the
      next instruction is executed, single-stepping on it by kprobes must be
      prohibited.
      
      However, kprobes usually executes those instructions directly on trampoline
      buffer (a.k.a. kprobe-booster), except for the kprobes which has
      post_handler. Thus if kprobe user probes MOV SS with post_handler, it will
      do single-stepping on the MOV SS.
      
      This means it is safe that if it is used via ftrace or perf/bpf since those
      don't use the post_handler.
      
      Anyway, since the stack switching is a rare case, it is safer just
      rejecting kprobes on such instructions.
      Signed-off-by: NMasami Hiramatsu <mhiramat@kernel.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
      Cc: Francis Deslauriers <francis.deslauriers@efficios.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Alexei Starovoitov <ast@kernel.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: "H . Peter Anvin" <hpa@zytor.com>
      Cc: Yonghong Song <yhs@fb.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: "David S . Miller" <davem@davemloft.net>
      Link: https://lkml.kernel.org/r/152587069574.17316.3311695234863248641.stgit@devbox
      ee6a7354
  3. 09 3月, 2018 1 次提交
    • F
      x86/kprobes: Fix kernel crash when probing .entry_trampoline code · c07a8f8b
      Francis Deslauriers 提交于
      Disable the kprobe probing of the entry trampoline:
      
      .entry_trampoline is a code area that is used to ensure page table
      isolation between userspace and kernelspace.
      
      At the beginning of the execution of the trampoline, we load the
      kernel's CR3 register. This has the effect of enabling the translation
      of the kernel virtual addresses to physical addresses. Before this
      happens most kernel addresses can not be translated because the running
      process' CR3 is still used.
      
      If a kprobe is placed on the trampoline code before that change of the
      CR3 register happens the kernel crashes because int3 handling pages are
      not accessible.
      
      To fix this, add the .entry_trampoline section to the kprobe blacklist
      to prohibit the probing of code before all the kernel pages are
      accessible.
      Signed-off-by: NFrancis Deslauriers <francis.deslauriers@efficios.com>
      Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: mathieu.desnoyers@efficios.com
      Cc: mhiramat@kernel.org
      Link: http://lkml.kernel.org/r/1520565492-4637-2-git-send-email-francis.deslauriers@efficios.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      c07a8f8b
  4. 13 1月, 2018 2 次提交
  5. 04 10月, 2017 1 次提交
    • M
      kprobes/x86: Remove IRQ disabling from jprobe handlers · b664d57f
      Masami Hiramatsu 提交于
      Jprobes actually don't need to disable IRQs while calling
      handlers, because of how we specify the kernel interface in
      Documentation/kprobes.txt:
      
      -----
       Probe handlers are run with preemption disabled.  Depending on the
       architecture and optimization state, handlers may also run with
       interrupts disabled (e.g., kretprobe handlers and optimized kprobe
       handlers run without interrupt disabled on x86/x86-64).
      -----
      
      So let's remove IRQ disabling from jprobes too.
      Signed-off-by: NMasami Hiramatsu <mhiramat@kernel.org>
      Cc: Alexei Starovoitov <ast@fb.com>
      Cc: Alexei Starovoitov <ast@kernel.org>
      Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul E . McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/150701508194.32266.14458959863314097305.stgit@devboxSigned-off-by: NIngo Molnar <mingo@kernel.org>
      b664d57f
  6. 28 9月, 2017 1 次提交
  7. 24 7月, 2017 1 次提交
  8. 27 5月, 2017 1 次提交
  9. 09 5月, 2017 1 次提交
  10. 12 4月, 2017 8 次提交
    • M
      kprobes/x86: Consolidate insn decoder users for copying code · a8d11cd0
      Masami Hiramatsu 提交于
      Consolidate x86 instruction decoder users on the path of
      copying original code for kprobes.
      
      Kprobes decodes the same instruction a maximum of 3 times when
      preparing the instruction buffer:
      
       - The first time for getting the length of the instruction,
       - the 2nd for adjusting displacement,
       - and the 3rd for checking whether the instruction is boostable or not.
      
      For each time, the actual decoding target address is slightly
      different (1st is original address or recovered instruction buffer,
      2nd and 3rd are pointing to the copied buffer), but all have
      the same instruction.
      
      Thus, this patch also changes the target address to the copied
      buffer at first and reuses the decoded "insn" for displacement
      adjusting and checking boostability.
      Signed-off-by: NMasami Hiramatsu <mhiramat@kernel.org>
      Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
      Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: David S . Miller <davem@davemloft.net>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ye Xiaolong <xiaolong.ye@intel.com>
      Link: http://lkml.kernel.org/r/149076389643.22469.13151892839998777373.stgit@devboxSigned-off-by: NIngo Molnar <mingo@kernel.org>
      a8d11cd0
    • M
      kprobes/x86: Use probe_kernel_read() instead of memcpy() · ea1e34fc
      Masami Hiramatsu 提交于
      Use probe_kernel_read() for avoiding unexpected faults while
      copying kernel text in __recover_probed_insn(),
      __recover_optprobed_insn() and __copy_instruction().
      Signed-off-by: NMasami Hiramatsu <mhiramat@kernel.org>
      Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
      Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: David S . Miller <davem@davemloft.net>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ye Xiaolong <xiaolong.ye@intel.com>
      Link: http://lkml.kernel.org/r/149076382624.22469.10091613887942958518.stgit@devboxSigned-off-by: NIngo Molnar <mingo@kernel.org>
      ea1e34fc
    • M
      kprobes/x86: Set kprobes pages read-only · d0381c81
      Masami Hiramatsu 提交于
      Set the pages which is used for kprobes' singlestep buffer
      and optprobe's trampoline instruction buffer to readonly.
      This can prevent unexpected (or unintended) instruction
      modification.
      
      This also passes rodata_test as below.
      
      Without this patch, rodata_test shows a warning:
      
        WARNING: CPU: 0 PID: 1 at arch/x86/mm/dump_pagetables.c:235 note_page+0x7a9/0xa20
        x86/mm: Found insecure W+X mapping at address ffffffffa0000000/0xffffffffa0000000
      
      With this fix, no W+X pages are found:
      
        x86/mm: Checked W+X mappings: passed, no W+X pages found.
        rodata_test: all tests were successful
      Reported-by: NAndrey Ryabinin <aryabinin@virtuozzo.com>
      Signed-off-by: NMasami Hiramatsu <mhiramat@kernel.org>
      Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
      Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: David S . Miller <davem@davemloft.net>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ye Xiaolong <xiaolong.ye@intel.com>
      Link: http://lkml.kernel.org/r/149076375592.22469.14174394514338612247.stgit@devboxSigned-off-by: NIngo Molnar <mingo@kernel.org>
      d0381c81
    • M
      kprobes/x86: Make boostable flag boolean · 490154bc
      Masami Hiramatsu 提交于
      Make arch_specific_insn.boostable to boolean, since it has
      only 2 states, boostable or not. So it is better to use
      boolean from the viewpoint of code readability.
      Signed-off-by: NMasami Hiramatsu <mhiramat@kernel.org>
      Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
      Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: David S . Miller <davem@davemloft.net>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ye Xiaolong <xiaolong.ye@intel.com>
      Link: http://lkml.kernel.org/r/149076368566.22469.6322906866458231844.stgit@devboxSigned-off-by: NIngo Molnar <mingo@kernel.org>
      490154bc
    • M
      kprobes/x86: Do not modify singlestep buffer while resuming · 804dec5b
      Masami Hiramatsu 提交于
      Do not modify singlestep execution buffer (kprobe.ainsn.insn)
      while resuming from single-stepping, instead, modifies
      the buffer to add a jump back instruction at preparing
      buffer.
      Signed-off-by: NMasami Hiramatsu <mhiramat@kernel.org>
      Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
      Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: David S . Miller <davem@davemloft.net>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ye Xiaolong <xiaolong.ye@intel.com>
      Link: http://lkml.kernel.org/r/149076361560.22469.1610155860343077495.stgit@devboxSigned-off-by: NIngo Molnar <mingo@kernel.org>
      804dec5b
    • M
      kprobes/x86: Use instruction decoder for booster · 17880e4d
      Masami Hiramatsu 提交于
      Use x86 instruction decoder for checking whether the probed
      instruction is able to boost or not, instead of hand-written
      code.
      Signed-off-by: NMasami Hiramatsu <mhiramat@kernel.org>
      Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
      Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: David S . Miller <davem@davemloft.net>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ye Xiaolong <xiaolong.ye@intel.com>
      Link: http://lkml.kernel.org/r/149076354563.22469.13379472209338986858.stgit@devboxSigned-off-by: NIngo Molnar <mingo@kernel.org>
      17880e4d
    • M
      kprobes/x86: Fix the description of __copy_instruction() · 129d17e8
      Masami Hiramatsu 提交于
      Fix the description comment of __copy_instruction() function
      since it has already been changed to return the length of the
      copied instruction.
      Signed-off-by: NMasami Hiramatsu <mhiramat@kernel.org>
      Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
      Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: David S . Miller <davem@davemloft.net>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ye Xiaolong <xiaolong.ye@intel.com>
      Link: http://lkml.kernel.org/r/149076347582.22469.3775133607244923462.stgit@devboxSigned-off-by: NIngo Molnar <mingo@kernel.org>
      129d17e8
    • M
      kprobes/x86: Fix kprobe-booster not to boost far call instructions · bd0b9067
      Masami Hiramatsu 提交于
      Fix the kprobe-booster not to boost far call instruction,
      because a call may store the address in the single-step
      execution buffer to the stack, which should be modified
      after single stepping.
      
      Currently, this instruction will be filtered as not
      boostable in resume_execution(), so this is not a
      critical issue.
      Signed-off-by: NMasami Hiramatsu <mhiramat@kernel.org>
      Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
      Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: David S . Miller <davem@davemloft.net>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ye Xiaolong <xiaolong.ye@intel.com>
      Link: http://lkml.kernel.org/r/149076340615.22469.14066273186134229909.stgit@devboxSigned-off-by: NIngo Molnar <mingo@kernel.org>
      bd0b9067
  11. 02 3月, 2017 1 次提交
  12. 01 3月, 2017 1 次提交
  13. 06 2月, 2017 1 次提交
  14. 25 12月, 2016 1 次提交
  15. 16 10月, 2016 2 次提交
    • D
      kprobes: Unpoison stack in jprobe_return() for KASAN · 9f7d416c
      Dmitry Vyukov 提交于
      I observed false KSAN positives in the sctp code, when
      sctp uses jprobe_return() in jsctp_sf_eat_sack().
      
      The stray 0xf4 in shadow memory are stack redzones:
      
      [     ] ==================================================================
      [     ] BUG: KASAN: stack-out-of-bounds in memcmp+0xe9/0x150 at addr ffff88005e48f480
      [     ] Read of size 1 by task syz-executor/18535
      [     ] page:ffffea00017923c0 count:0 mapcount:0 mapping:          (null) index:0x0
      [     ] flags: 0x1fffc0000000000()
      [     ] page dumped because: kasan: bad access detected
      [     ] CPU: 1 PID: 18535 Comm: syz-executor Not tainted 4.8.0+ #28
      [     ] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      [     ]  ffff88005e48f2d0 ffffffff82d2b849 ffffffff0bc91e90 fffffbfff10971e8
      [     ]  ffffed000bc91e90 ffffed000bc91e90 0000000000000001 0000000000000000
      [     ]  ffff88005e48f480 ffff88005e48f350 ffffffff817d3169 ffff88005e48f370
      [     ] Call Trace:
      [     ]  [<ffffffff82d2b849>] dump_stack+0x12e/0x185
      [     ]  [<ffffffff817d3169>] kasan_report+0x489/0x4b0
      [     ]  [<ffffffff817d31a9>] __asan_report_load1_noabort+0x19/0x20
      [     ]  [<ffffffff82d49529>] memcmp+0xe9/0x150
      [     ]  [<ffffffff82df7486>] depot_save_stack+0x176/0x5c0
      [     ]  [<ffffffff817d2031>] save_stack+0xb1/0xd0
      [     ]  [<ffffffff817d27f2>] kasan_slab_free+0x72/0xc0
      [     ]  [<ffffffff817d05b8>] kfree+0xc8/0x2a0
      [     ]  [<ffffffff85b03f19>] skb_free_head+0x79/0xb0
      [     ]  [<ffffffff85b0900a>] skb_release_data+0x37a/0x420
      [     ]  [<ffffffff85b090ff>] skb_release_all+0x4f/0x60
      [     ]  [<ffffffff85b11348>] consume_skb+0x138/0x370
      [     ]  [<ffffffff8676ad7b>] sctp_chunk_put+0xcb/0x180
      [     ]  [<ffffffff8676ae88>] sctp_chunk_free+0x58/0x70
      [     ]  [<ffffffff8677fa5f>] sctp_inq_pop+0x68f/0xef0
      [     ]  [<ffffffff8675ee36>] sctp_assoc_bh_rcv+0xd6/0x4b0
      [     ]  [<ffffffff8677f2c1>] sctp_inq_push+0x131/0x190
      [     ]  [<ffffffff867bad69>] sctp_backlog_rcv+0xe9/0xa20
      [ ... ]
      [     ] Memory state around the buggy address:
      [     ]  ffff88005e48f380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [     ]  ffff88005e48f400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [     ] >ffff88005e48f480: f4 f4 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [     ]                    ^
      [     ]  ffff88005e48f500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [     ]  ffff88005e48f580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [     ] ==================================================================
      
      KASAN stack instrumentation poisons stack redzones on function entry
      and unpoisons them on function exit. If a function exits abnormally
      (e.g. with a longjmp like jprobe_return()), stack redzones are left
      poisoned. Later this leads to random KASAN false reports.
      
      Unpoison stack redzones in the frames we are going to jump over
      before doing actual longjmp in jprobe_return().
      Signed-off-by: NDmitry Vyukov <dvyukov@google.com>
      Acked-by: NMasami Hiramatsu <mhiramat@kernel.org>
      Reviewed-by: NMark Rutland <mark.rutland@arm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
      Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Cc: Alexander Potapenko <glider@google.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
      Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: kasan-dev@googlegroups.com
      Cc: surovegin@google.com
      Cc: rostedt@goodmis.org
      Link: http://lkml.kernel.org/r/1476454043-101898-1-git-send-email-dvyukov@google.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      9f7d416c
    • D
      kprobes: Avoid false KASAN reports during stack copy · 9254139a
      Dmitry Vyukov 提交于
      Kprobes save and restore raw stack chunks with memcpy().
      With KASAN these chunks can contain poisoned stack redzones,
      as the result memcpy() interceptor produces false
      stack out-of-bounds reports.
      
      Use __memcpy() instead of memcpy() for stack copying.
      __memcpy() is not instrumented by KASAN and does not lead
      to the false reports.
      
      Currently there is a spew of KASAN reports during boot
      if CONFIG_KPROBES_SANITY_TEST is enabled:
      
      [   ] Kprobe smoke test: started
      [   ] ==================================================================
      [   ] BUG: KASAN: stack-out-of-bounds in setjmp_pre_handler+0x17c/0x280 at addr ffff88085259fba8
      [   ] Read of size 64 by task swapper/0/1
      [   ] page:ffffea00214967c0 count:0 mapcount:0 mapping:          (null) index:0x0
      [   ] flags: 0x2fffff80000000()
      [   ] page dumped because: kasan: bad access detected
      [...]
      Reported-by: NCAI Qian <caiqian@redhat.com>
      Tested-by: NCAI Qian <caiqian@redhat.com>
      Signed-off-by: NDmitry Vyukov <dvyukov@google.com>
      Acked-by: NMasami Hiramatsu <mhiramat@kernel.org>
      Cc: Alexander Potapenko <glider@google.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: kasan-dev@googlegroups.com
      [ Improved various details. ]
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      9254139a
  16. 20 9月, 2016 1 次提交
  17. 14 6月, 2016 1 次提交
    • M
      kprobes/x86: Clear TF bit in fault on single-stepping · dcfc4724
      Masami Hiramatsu 提交于
      Fix kprobe_fault_handler() to clear the TF (trap flag) bit of
      the flags register in the case of a fault fixup on single-stepping.
      
      If we put a kprobe on the instruction which caused a
      page fault (e.g. actual mov instructions in copy_user_*),
      that fault happens on the single-stepping buffer. In this
      case, kprobes resets running instance so that the CPU can
      retry execution on the original ip address.
      
      However, current code forgets to reset the TF bit. Since this
      fault happens with TF bit set for enabling single-stepping,
      when it retries, it causes a debug exception and kprobes
      can not handle it because it already reset itself.
      
      On the most of x86-64 platform, it can be easily reproduced
      by using kprobe tracer. E.g.
      
        # cd /sys/kernel/debug/tracing
        # echo p copy_user_enhanced_fast_string+5 > kprobe_events
        # echo 1 > events/kprobes/enable
      
      And you'll see a kernel panic on do_debug(), since the debug
      trap is not handled by kprobes.
      
      To fix this problem, we just need to clear the TF bit when
      resetting running kprobe.
      Signed-off-by: NMasami Hiramatsu <mhiramat@kernel.org>
      Reviewed-by: NAnanth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
      Acked-by: NSteven Rostedt <rostedt@goodmis.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Cc: systemtap@sourceware.org
      Cc: stable@vger.kernel.org # All the way back to ancient kernels
      Link: http://lkml.kernel.org/r/20160611140648.25885.37482.stgit@devbox
      [ Updated the comments. ]
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      dcfc4724
  18. 29 4月, 2016 1 次提交
  19. 29 2月, 2016 1 次提交
    • J
      x86/kprobes: Mark kretprobe_trampoline() stack frame as non-standard · 87aaff2a
      Josh Poimboeuf 提交于
      objtool reports the following warning for kretprobe_trampoline():
      
        arch/x86/kernel/kprobes/core.o: warning: objtool: kretprobe_trampoline()+0x20: call without frame pointer save/setup
      
      kretprobes are a special case where the stack is intentionally wrong.
      The return address isn't known at the beginning of the trampoline, so
      the stack frame can't be set up properly before it calls
      trampoline_handler().
      
      Because kretprobe handlers don't sleep, the frame pointer doesn't *have*
      to be accurate in the trampoline.  So it's ok to tell objtool to ignore
      it.  This results in no actual changes to the generated code.
      Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Bernd Petrovitsch <bernd@petrovitsch.priv.at>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Chris J Arges <chris.j.arges@canonical.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Jiri Slaby <jslaby@suse.cz>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Michal Marek <mmarek@suse.cz>
      Cc: Namhyung Kim <namhyung@gmail.com>
      Cc: Pedro Alves <palves@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: live-patching@vger.kernel.org
      Link: http://lkml.kernel.org/r/7eaf37de52456ff822ffc86b928edb5d48a40ef1.1456719558.git.jpoimboe@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      87aaff2a
  20. 24 2月, 2016 1 次提交
    • J
      x86/kprobes: Get rid of kretprobe_trampoline_holder() · c1c355ce
      Josh Poimboeuf 提交于
      The kretprobe_trampoline_holder() wrapper around kretprobe_trampoline()
      isn't used anywhere and adds some unnecessary frame pointer instructions
      which never execute.  Instead, just make kretprobe_trampoline() a proper
      ELF function.
      Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Acked-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Bernd Petrovitsch <bernd@petrovitsch.priv.at>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Chris J Arges <chris.j.arges@canonical.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Jiri Slaby <jslaby@suse.cz>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Michal Marek <mmarek@suse.cz>
      Cc: Namhyung Kim <namhyung@gmail.com>
      Cc: Pedro Alves <palves@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: live-patching@vger.kernel.org
      Link: http://lkml.kernel.org/r/92d921b102fb865a7c254cfde9e4a0a72b9a781e.1453405861.git.jpoimboe@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      c1c355ce
  21. 18 2月, 2016 1 次提交
  22. 23 3月, 2015 1 次提交
  23. 17 3月, 2015 1 次提交
  24. 21 2月, 2015 2 次提交
    • P
      kprobes/x86: Check for invalid ftrace location in __recover_probed_insn() · 2a6730c8
      Petr Mladek 提交于
      __recover_probed_insn() should always be called from an address
      where an instructions starts. The check for ftrace_location()
      might help to discover a potential inconsistency.
      
      This patch adds WARN_ON() when the inconsistency is detected.
      Also it adds handling of the situation when the original code
      can not get recovered.
      Suggested-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Signed-off-by: NPetr Mladek <pmladek@suse.cz>
      Cc: Ananth NMavinakayanahalli <ananth@in.ibm.com>
      Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Link: http://lkml.kernel.org/r/1424441250-27146-3-git-send-email-pmladek@suse.czSigned-off-by: NIngo Molnar <mingo@kernel.org>
      2a6730c8
    • P
      kprobes/x86: Use 5-byte NOP when the code might be modified by ftrace · 650b7b23
      Petr Mladek 提交于
      can_probe() checks if the given address points to the beginning
      of an instruction. It analyzes all the instructions from the
      beginning of the function until the given address. The code
      might be modified by another Kprobe. In this case, the current
      code is read into a buffer, int3 breakpoint is replaced by the
      saved opcode in the buffer, and can_probe() analyzes the buffer
      instead.
      
      There is a bug that __recover_probed_insn() tries to restore
      the original code even for Kprobes using the ftrace framework.
      But in this case, the opcode is not stored. See the difference
      between arch_prepare_kprobe() and arch_prepare_kprobe_ftrace().
      The opcode is stored by arch_copy_kprobe() only from
      arch_prepare_kprobe().
      
      This patch makes Kprobe to use the ideal 5-byte NOP when the
      code can be modified by ftrace. It is the original instruction,
      see ftrace_make_nop() and ftrace_nop_replace().
      
      Note that we always need to use the NOP for ftrace locations.
      Kprobes do not block ftrace and the instruction might get
      modified at anytime. It might even be in an inconsistent state
      because it is modified step by step using the int3 breakpoint.
      
      The patch also fixes indentation of the touched comment.
      
      Note that I found this problem when playing with Kprobes. I did
      it on x86_64 with gcc-4.8.3 that supported -mfentry. I modified
      samples/kprobes/kprobe_example.c and added offset 5 to put
      the probe right after the fentry area:
      
       static struct kprobe kp = {
       	.symbol_name	= "do_fork",
      +	.offset = 5,
       };
      
      Then I was able to load kprobe_example before jprobe_example
      but not the other way around:
      
        $> modprobe jprobe_example
        $> modprobe kprobe_example
        modprobe: ERROR: could not insert 'kprobe_example': Invalid or incomplete multibyte or wide character
      
      It did not make much sense and debugging pointed to the bug
      described above.
      Signed-off-by: NPetr Mladek <pmladek@suse.cz>
      Acked-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Ananth NMavinakayanahalli <ananth@in.ibm.com>
      Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Link: http://lkml.kernel.org/r/1424441250-27146-2-git-send-email-pmladek@suse.czSigned-off-by: NIngo Molnar <mingo@kernel.org>
      650b7b23
  25. 19 2月, 2015 1 次提交
  26. 15 1月, 2015 1 次提交
    • S
      ftrace/jprobes/x86: Fix conflict between jprobes and function graph tracing · 237d28db
      Steven Rostedt (Red Hat) 提交于
      If the function graph tracer traces a jprobe callback, the system will
      crash. This can easily be demonstrated by compiling the jprobe
      sample module that is in the kernel tree, loading it and running the
      function graph tracer.
      
       # modprobe jprobe_example.ko
       # echo function_graph > /sys/kernel/debug/tracing/current_tracer
       # ls
      
      The first two commands end up in a nice crash after the first fork.
      (do_fork has a jprobe attached to it, so "ls" just triggers that fork)
      
      The problem is caused by the jprobe_return() that all jprobe callbacks
      must end with. The way jprobes works is that the function a jprobe
      is attached to has a breakpoint placed at the start of it (or it uses
      ftrace if fentry is supported). The breakpoint handler (or ftrace callback)
      will copy the stack frame and change the ip address to return to the
      jprobe handler instead of the function. The jprobe handler must end
      with jprobe_return() which swaps the stack and does an int3 (breakpoint).
      This breakpoint handler will then put back the saved stack frame,
      simulate the instruction at the beginning of the function it added
      a breakpoint to, and then continue on.
      
      For function tracing to work, it hijakes the return address from the
      stack frame, and replaces it with a hook function that will trace
      the end of the call. This hook function will restore the return
      address of the function call.
      
      If the function tracer traces the jprobe handler, the hook function
      for that handler will not be called, and its saved return address
      will be used for the next function. This will result in a kernel crash.
      
      To solve this, pause function tracing before the jprobe handler is called
      and unpause it before it returns back to the function it probed.
      
      Some other updates:
      
      Used a variable "saved_sp" to hold kcb->jprobe_saved_sp. This makes the
      code look a bit cleaner and easier to understand (various tries to fix
      this bug required this change).
      
      Note, if fentry is being used, jprobes will change the ip address before
      the function graph tracer runs and it will not be able to trace the
      function that the jprobe is probing.
      
      Link: http://lkml.kernel.org/r/20150114154329.552437962@goodmis.org
      
      Cc: stable@vger.kernel.org # 2.6.30+
      Acked-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      237d28db