Skip to content
Snippets Groups Projects
  1. May 14, 2018
    • Josh Poimboeuf's avatar
      objtool: Support GCC 8 switch tables · fd35c88b
      Josh Poimboeuf authored
      
      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: default avatarArnd Bergmann <arnd@arndb.de>
      Reported-by: default avatarkbuild test robot <lkp@intel.com>
      Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Acked-by: default avatarPeter 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@treble
      
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      fd35c88b
    • Josh Poimboeuf's avatar
      objtool: Support GCC 8's cold subfunctions · 13810435
      Josh Poimboeuf authored
      
      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: default avatardamian <damian.tometzki@icloud.com>
      Reported-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Acked-by: default avatarPeter 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.com
      
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      13810435
    • Josh Poimboeuf's avatar
      objtool: Fix "noreturn" detection for recursive sibling calls · 0afd0d9e
      Josh Poimboeuf authored
      
      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: default avatarRandy Dunlap <rdunlap@infradead.org>
      Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Acked-by: default avatarPeter 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.com
      
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      0afd0d9e
    • Ingo Molnar's avatar
      objtool, kprobes/x86: Sync the latest <asm/insn.h> header with... · 4fe875e4
      Ingo Molnar authored
      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: default avatarIngo Molnar <mingo@kernel.org>
      4fe875e4
    • Alexei Starovoitov's avatar
      x86/cpufeature: Guard asm_volatile_goto usage for BPF compilation · b1ae32db
      Alexei Starovoitov authored
      
      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: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarThomas 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
    • Masami Hiramatsu's avatar
      uprobes/x86: Prohibit probing on MOV SS instruction · 13ebe18c
      Masami Hiramatsu authored
      
      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: default avatarMasami Hiramatsu <mhiramat@kernel.org>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Acked-by: default avatarOleg 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
    • Masami Hiramatsu's avatar
      kprobes/x86: Prohibit probing on exception masking instructions · ee6a7354
      Masami Hiramatsu authored
      
      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: default avatarMasami Hiramatsu <mhiramat@kernel.org>
      Signed-off-by: default avatarThomas 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
    • Tetsuo Handa's avatar
      x86/kexec: Avoid double free_page() upon do_kexec_load() failure · a466ef76
      Tetsuo Handa authored
      >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: default avatarsyzbot <syzbot+d96f60296ef613fe1d69@syzkaller.appspotmail.com>
      Signed-off-by: default avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Acked-by: default avatarBaoquan 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
  2. May 13, 2018
  3. May 12, 2018