1. 15 5月, 2018 1 次提交
    • J
      objtool: Detect RIP-relative switch table references · 6f5ec299
      Josh Poimboeuf 提交于
      Typically a switch table can be found by detecting a .rodata access
      followed an indirect jump:
      
          1969:	4a 8b 0c e5 00 00 00 	mov    0x0(,%r12,8),%rcx
          1970:	00
      			196d: R_X86_64_32S	.rodata+0x438
          1971:	e9 00 00 00 00       	jmpq   1976 <dispc_runtime_suspend+0xb6a>
      			1972: R_X86_64_PC32	__x86_indirect_thunk_rcx-0x4
      
      Randy Dunlap reported a case (seen with GCC 4.8) where the .rodata
      access uses RIP-relative addressing:
      
          19bd:	48 8b 3d 00 00 00 00 	mov    0x0(%rip),%rdi        # 19c4 <dispc_runtime_suspend+0xbb8>
      			19c0: R_X86_64_PC32	.rodata+0x45c
          19c4:	e9 00 00 00 00       	jmpq   19c9 <dispc_runtime_suspend+0xbbd>
      			19c5: R_X86_64_PC32	__x86_indirect_thunk_rdi-0x4
      
      In this case the relocation addend needs to be adjusted accordingly in
      order to find the location of the switch table.
      
      The fix is for case 3 (as described in the comments), but also make the
      existing case 1 & 2 checks more precise by only adjusting the addend for
      R_X86_64_PC32 relocations.
      
      This fixes the following warnings:
      
        drivers/video/fbdev/omap2/omapfb/dss/dispc.o: warning: objtool: dispc_runtime_suspend()+0xbb8: sibling call from callable instruction with modified stack frame
        drivers/video/fbdev/omap2/omapfb/dss/dispc.o: warning: objtool: dispc_runtime_resume()+0xcc5: sibling call from callable instruction with modified stack frame
      Reported-by: NRandy Dunlap <rdunlap@infradead.org>
      Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/b6098294fd67afb69af8c47c9883d7a68bf0f8ea.1526305958.git.jpoimboe@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      6f5ec299
  2. 14 5月, 2018 8 次提交
    • J
      objtool: Support GCC 8 switch tables · fd35c88b
      Josh Poimboeuf 提交于
      With GCC 8, some issues were found with the objtool switch table
      detection.
      
      1) In the .rodata section, immediately after the switch table, there can
         be another object which contains a pointer to the function which had
         the switch statement.  In this case objtool wrongly considers the
         function pointer to be part of the switch table.  Fix it by:
      
         a) making sure there are no pointers to the beginning of the
            function; and
      
         b) making sure there are no gaps in the switch table.
      
         Only the former was needed, the latter adds additional protection for
         future optimizations.
      
      2) In find_switch_table(), case 1 and case 2 are missing the check to
         ensure that the .rodata switch table data is anonymous, i.e. that it
         isn't already associated with an ELF symbol.  Fix it by adding the
         same find_symbol_containing() check which is used for case 3.
      
      This fixes the following warnings with GCC 8:
      
        drivers/block/virtio_blk.o: warning: objtool: virtio_queue_rq()+0x0: stack state mismatch: cfa1=7+8 cfa2=7+72
        net/ipv6/icmp.o: warning: objtool: icmpv6_rcv()+0x0: stack state mismatch: cfa1=7+8 cfa2=7+64
        drivers/usb/core/quirks.o: warning: objtool: quirks_param_set()+0x0: stack state mismatch: cfa1=7+8 cfa2=7+48
        drivers/mtd/nand/raw/nand_hynix.o: warning: objtool: hynix_nand_decode_id()+0x0: stack state mismatch: cfa1=7+8 cfa2=7+24
        drivers/mtd/nand/raw/nand_samsung.o: warning: objtool: samsung_nand_decode_id()+0x0: stack state mismatch: cfa1=7+8 cfa2=7+32
        drivers/gpu/drm/nouveau/nvkm/subdev/top/gk104.o: warning: objtool: gk104_top_oneinit()+0x0: stack state mismatch: cfa1=7+8 cfa2=7+64
      Reported-by: NArnd Bergmann <arnd@arndb.de>
      Reported-by: Nkbuild test robot <lkp@intel.com>
      Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: David Laight <David.Laight@ACULAB.COM>
      Cc: Greg KH <gregkh@linuxfoundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: damian <damian.tometzki@icloud.com>
      Link: http://lkml.kernel.org/r/20180510224849.xwi34d6tzheb5wgw@trebleSigned-off-by: NIngo Molnar <mingo@kernel.org>
      fd35c88b
    • J
      objtool: Support GCC 8's cold subfunctions · 13810435
      Josh Poimboeuf 提交于
      GCC 8 moves a lot of unlikely code out of line to "cold" subfunctions in
      .text.unlikely.  Properly detect the new subfunctions and treat them as
      extensions of the original functions.
      
      This fixes a bunch of warnings like:
      
        kernel/cgroup/cgroup.o: warning: objtool: parse_cgroup_root_flags()+0x33: sibling call from callable instruction with modified stack frame
        kernel/cgroup/cgroup.o: warning: objtool: cgroup_addrm_files()+0x290: sibling call from callable instruction with modified stack frame
        kernel/cgroup/cgroup.o: warning: objtool: cgroup_apply_control_enable()+0x25b: sibling call from callable instruction with modified stack frame
        kernel/cgroup/cgroup.o: warning: objtool: rebind_subsystems()+0x325: sibling call from callable instruction with modified stack frame
      Reported-and-tested-by: Ndamian <damian.tometzki@icloud.com>
      Reported-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: David Laight <David.Laight@ACULAB.COM>
      Cc: Greg KH <gregkh@linuxfoundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/0965e7fcfc5f31a276f0c7f298ff770c19b68706.1525923412.git.jpoimboe@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      13810435
    • J
      objtool: Fix "noreturn" detection for recursive sibling calls · 0afd0d9e
      Josh Poimboeuf 提交于
      Objtool has some crude logic for detecting static "noreturn" functions
      (aka "dead ends").  This is necessary for being able to correctly follow
      GCC code flow when such functions are called.
      
      It's remotely possible for two functions to call each other via sibling
      calls.  If they don't have RET instructions, objtool's noreturn
      detection logic goes into a recursive loop:
      
        drivers/char/ipmi/ipmi_ssif.o: warning: objtool: return_hosed_msg()+0x0: infinite recursion (objtool bug!)
        drivers/char/ipmi/ipmi_ssif.o: warning: objtool: deliver_recv_msg()+0x0: infinite recursion (objtool bug!)
      
      Instead of reporting an error in this case, consider the functions to be
      non-dead-ends.
      Reported-and-tested-by: NRandy Dunlap <rdunlap@infradead.org>
      Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: David Laight <David.Laight@ACULAB.COM>
      Cc: Greg KH <gregkh@linuxfoundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: damian <damian.tometzki@icloud.com>
      Link: http://lkml.kernel.org/r/7cc156408c5781a1f62085d352ced1fe39fe2f91.1525923412.git.jpoimboe@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      0afd0d9e
    • I
      objtool, kprobes/x86: Sync the latest <asm/insn.h> header with... · 4fe875e4
      Ingo Molnar 提交于
      objtool, kprobes/x86: Sync the latest <asm/insn.h> header with tools/objtool/arch/x86/include/asm/insn.h
      
      The following commit:
      
        ee6a7354: kprobes/x86: Prohibit probing on exception masking instructions
      
      Modified <asm/insn.h>, adding the insn_masking_exception() function.
      
      Sync the tooling version of the header to it, to fix this warning:
      
        Warning: synced file at 'tools/objtool/arch/x86/include/asm/insn.h' differs from latest kernel version at 'arch/x86/include/asm/insn.h'
      
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Thomas 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>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      4fe875e4
    • A
      x86/cpufeature: Guard asm_volatile_goto usage for BPF compilation · b1ae32db
      Alexei Starovoitov 提交于
      Workaround for the sake of BPF compilation which utilizes kernel
      headers, but clang does not support ASM GOTO and fails the build.
      
      Fixes: d0266046 ("x86: Remove FAST_FEATURE_TESTS")
      Suggested-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: daniel@iogearbox.net
      Cc: peterz@infradead.org
      Cc: netdev@vger.kernel.org
      Cc: bp@alien8.de
      Cc: yhs@fb.com
      Cc: kernel-team@fb.com
      Cc: torvalds@linux-foundation.org
      Cc: davem@davemloft.net
      Link: https://lkml.kernel.org/r/20180513193222.1997938-1-ast@kernel.org
      b1ae32db
    • M
      uprobes/x86: Prohibit probing on MOV SS instruction · 13ebe18c
      Masami Hiramatsu 提交于
      Since MOV SS and POP SS instructions will delay the exceptions until the
      next instruction is executed, single-stepping on it by uprobes must be
      prohibited.
      
      uprobe already rejects probing on POP SS (0x1f), but allows probing on MOV
      SS (0x8e and reg == 2).  This checks the target instruction and if it is
      MOV SS or POP SS, returns -ENOTSUPP to reject probing.
      Signed-off-by: NMasami Hiramatsu <mhiramat@kernel.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NOleg Nesterov <oleg@redhat.com>
      Cc: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
      Cc: Francis Deslauriers <francis.deslauriers@efficios.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/152587072544.17316.5950935243917346341.stgit@devbox
      13ebe18c
    • 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
    • T
      x86/kexec: Avoid double free_page() upon do_kexec_load() failure · a466ef76
      Tetsuo Handa 提交于
      >From ff82bedd3e12f0d3353282054ae48c3bd8c72012 Mon Sep 17 00:00:00 2001
      From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Date: Wed, 9 May 2018 12:12:39 +0900
      Subject: [PATCH v3] x86/kexec: avoid double free_page() upon do_kexec_load() failure.
      
      syzbot is reporting crashes after memory allocation failure inside
      do_kexec_load() [1]. This is because free_transition_pgtable() is called
      by both init_transition_pgtable() and machine_kexec_cleanup() when memory
      allocation failed inside init_transition_pgtable().
      
      Regarding 32bit code, machine_kexec_free_page_tables() is called by both
      machine_kexec_alloc_page_tables() and machine_kexec_cleanup() when memory
      allocation failed inside machine_kexec_alloc_page_tables().
      
      Fix this by leaving the error handling to machine_kexec_cleanup()
      (and optionally setting NULL after free_page()).
      
      [1] https://syzkaller.appspot.com/bug?id=91e52396168cf2bdd572fe1e1bc0bc645c1c6b40
      
      Fixes: f5deb796 ("x86: kexec: Use one page table in x86_64 machine_kexec")
      Fixes: 92be3d6b ("kexec/i386: allocate page table pages dynamically")
      Reported-by: Nsyzbot <syzbot+d96f60296ef613fe1d69@syzkaller.appspotmail.com>
      Signed-off-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NBaoquan He <bhe@redhat.com>
      Cc: thomas.lendacky@amd.com
      Cc: prudo@linux.vnet.ibm.com
      Cc: Huang Ying <ying.huang@intel.com>
      Cc: syzkaller-bugs@googlegroups.com
      Cc: takahiro.akashi@linaro.org
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: akpm@linux-foundation.org
      Cc: dyoung@redhat.com
      Cc: kirill.shutemov@linux.intel.com
      Link: https://lkml.kernel.org/r/201805091942.DGG12448.tMFVFSJFQOOLHO@I-love.SAKURA.ne.jp
      a466ef76
  3. 13 5月, 2018 3 次提交
  4. 12 5月, 2018 28 次提交