17 Dec, 2018

2 commits

  • [ Upstream commit 22566c1603030f0a036ad564634b064ad1a55db2 ]

    Because find_symbol_by_name() traverses the same lists as
    read_symbols(), changing sym->name in place without copying it affects
    the result of find_symbol_by_name(). In the case where a ".cold"
    function precedes its parent in sec->symbol_list, it can result in a
    function being considered a parent of itself. This leads to function
    length being set to 0 and other consequent side-effects including a
    segfault in add_switch_table(). The effects of this bug are only
    visible when building with -ffunction-sections in KCFLAGS.

    Fix by copying the search string instead of modifying it in place.

    Signed-off-by: Artem Savkov
    Signed-off-by: Josh Poimboeuf
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Fixes: 13810435b9a7 ("objtool: Support GCC 8's cold subfunctions")
    Link: http://lkml.kernel.org/r/910abd6b5a4945130fd44f787c24e07b9e07c8da.1542736240.git.jpoimboe@redhat.com
    Signed-off-by: Ingo Molnar
    Signed-off-by: Sasha Levin

    Artem Savkov
     
  • [ Upstream commit 0b9301fb632f7111a3293a30cc5b20f1b82ed08d ]

    If read_symbols() fails during second list traversal (the one dealing
    with ".cold" subfunctions) it frees the symbol, but never deletes it
    from the list/hash_table resulting in symbol being freed again in
    elf_close(). Fix it by just returning an error, leaving cleanup to
    elf_close().

    Signed-off-by: Artem Savkov
    Signed-off-by: Josh Poimboeuf
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Fixes: 13810435b9a7 ("objtool: Support GCC 8's cold subfunctions")
    Link: http://lkml.kernel.org/r/beac5a9b7da9e8be90223459dcbe07766ae437dd.1542736240.git.jpoimboe@redhat.com
    Signed-off-by: Ingo Molnar
    Signed-off-by: Sasha Levin

    Artem Savkov
     

24 Aug, 2018

1 commit

  • [ Upstream commit 08b393d01c88aff27347ed2b1b354eb4db2f1532 ]

    Since the following commit:

    cd77849a69cf ("objtool: Fix GCC 8 cold subfunction detection for aliased functions")

    ... if the kernel is built with EXTRA_CFLAGS='-fno-reorder-functions',
    objtool can get stuck in an infinite loop.

    That flag causes the new GCC 8 cold subfunctions to be placed in .text
    instead of .text.unlikely. But it also has an unfortunate quirk: in the
    symbol table, the subfunction (e.g., nmi_panic.cold.7) is nested inside
    the parent (nmi_panic).

    That function overlap confuses objtool, and causes it to get into an
    infinite loop in next_insn_same_func(). Here's Allan's description of
    the loop:

    "Objtool iterates through the instructions in nmi_panic using
    next_insn_same_func. Once it reaches the end of nmi_panic at 0x534 it
    jumps to 0x528 as that's the start of nmi_panic.cold.7. However, since
    the instructions starting at 0x528 are still associated with nmi_panic
    objtool will get stuck in a loop, continually jumping back to 0x528
    after reaching 0x534."

    Fix it by shortening the length of the parent function so that the
    functions no longer overlap.

    Reported-and-analyzed-by: Allan Xavier
    Signed-off-by: Josh Poimboeuf
    Cc: Allan Xavier
    Cc: Andy Lutomirski
    Cc: Borislav Petkov
    Cc: Brian Gerst
    Cc: Denys Vlasenko
    Cc: H. Peter Anvin
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Link: http://lkml.kernel.org/r/9e704c52bee651129b036be14feda317ae5606ae.1530136978.git.jpoimboe@redhat.com
    Signed-off-by: Ingo Molnar
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Josh Poimboeuf
     

11 Jul, 2018

1 commit

  • commit 9564a8cf422d7b58f6e857e3546d346fa970191e upstream.

    I tried building using a freshly built Make (4.2.1-69-g8a731d1), but
    already the objtool build broke with

    orc_dump.c: In function ‘orc_dump’:
    orc_dump.c:106:2: error: ‘elf_getshnum’ is deprecated [-Werror=deprecated-declarations]
    if (elf_getshdrnum(elf, &nr_sections)) {

    Turns out that with that new Make, the backslash was not removed, so cpp
    didn't see a #include directive, grep found nothing, and
    -DLIBELF_USE_DEPRECATED was wrongly put in CFLAGS.

    Now, that new Make behaviour is documented in their NEWS file:

    * WARNING: Backward-incompatibility!
    Number signs (#) appearing inside a macro reference or function invocation
    no longer introduce comments and should not be escaped with backslashes:
    thus a call such as:
    foo := $(shell echo '#')
    is legal. Previously the number sign needed to be escaped, for example:
    foo := $(shell echo '\#')
    Now this latter will resolve to "\#". If you want to write makefiles
    portable to both versions, assign the number sign to a variable:
    C := \#
    foo := $(shell echo '$C')
    This was claimed to be fixed in 3.81, but wasn't, for some reason.
    To detect this change search for 'nocomment' in the .FEATURES variable.

    This also fixes up the two make-cmd instances to replace # with $(pound)
    rather than with \#. There might very well be other places that need
    similar fixup in preparation for whatever future Make release contains
    the above change, but at least this builds an x86_64 defconfig with the
    new make.

    Link: https://bugzilla.kernel.org/show_bug.cgi?id=197847
    Cc: Randy Dunlap
    Signed-off-by: Rasmus Villemoes
    Signed-off-by: Masahiro Yamada
    Signed-off-by: Greg Kroah-Hartman

    Rasmus Villemoes
     

21 Jun, 2018

1 commit

  • …h/x86/include/asm/insn.h

    [ Upstream commit 4fe875e4bd3cae85ae6f6eaf77f63fabe613b66e ]

    The following commit:

    ee6a7354a362: 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: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    Ingo Molnar
     

05 Jun, 2018

5 commits

  • commit 0afd0d9e0e7879d666c1df2fa1bea4d8716909fe upstream.

    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: Randy Dunlap
    Signed-off-by: Josh Poimboeuf
    Acked-by: Peter Zijlstra (Intel)
    Cc: Arnd Bergmann
    Cc: David Laight
    Cc: Greg KH
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Cc: damian
    Link: http://lkml.kernel.org/r/7cc156408c5781a1f62085d352ced1fe39fe2f91.1525923412.git.jpoimboe@redhat.com
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Josh Poimboeuf
     
  • commit 7dec80ccbe310fb7e225bf21c48c672bb780ce7b upstream.

    With the following commit:

    fd35c88b7417 ("objtool: Support GCC 8 switch tables")

    I added a "can't find switch jump table" warning, to stop covering up
    silent failures if add_switch_table() can't find anything.

    That warning found yet another bug in the objtool switch table detection
    logic. For cases 1 and 2 (as described in the comments of
    find_switch_table()), the find_symbol_containing() check doesn't adjust
    the offset for RIP-relative switch jumps.

    Incidentally, this bug was already fixed for case 3 with:

    6f5ec2993b1f ("objtool: Detect RIP-relative switch table references")

    However, that commit missed the fix for cases 1 and 2.

    The different cases are now starting to look more and more alike. So
    fix the bug by consolidating them into a single case, by checking the
    original dynamic jump instruction in the case 3 loop.

    This also simplifies the code and makes it more robust against future
    switch table detection issues -- of which I'm sure there will be many...

    Switch table detection has been the most fragile area of objtool, by
    far. I long for the day when we'll have a GCC plugin for annotating
    switch tables. Linus asked me to delay such a plugin due to the
    flakiness of the plugin infrastructure in older versions of GCC, so this
    rickety code is what we're stuck with for now. At least the code is now
    a little simpler than it was.

    Reported-by: kbuild test robot
    Signed-off-by: Josh Poimboeuf
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Link: http://lkml.kernel.org/r/f400541613d45689086329432f3095119ffbc328.1526674218.git.jpoimboe@redhat.com
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Josh Poimboeuf
     
  • commit 6f5ec2993b1f39aed12fa6fd56e8dc2272ee8a33 upstream.

    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
    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
    19c0: R_X86_64_PC32 .rodata+0x45c
    19c4: e9 00 00 00 00 jmpq 19c9
    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: Randy Dunlap
    Signed-off-by: Josh Poimboeuf
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Link: http://lkml.kernel.org/r/b6098294fd67afb69af8c47c9883d7a68bf0f8ea.1526305958.git.jpoimboe@redhat.com
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Josh Poimboeuf
     
  • commit fd35c88b74170d9335530d9abf271d5d73eb5401 upstream.

    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: Arnd Bergmann
    Reported-by: kbuild test robot
    Signed-off-by: Josh Poimboeuf
    Acked-by: Peter Zijlstra (Intel)
    Cc: David Laight
    Cc: Greg KH
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Randy Dunlap
    Cc: Thomas Gleixner
    Cc: damian
    Link: http://lkml.kernel.org/r/20180510224849.xwi34d6tzheb5wgw@treble
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Josh Poimboeuf
     
  • commit 13810435b9a7014fb92eb715f77da488f3b65b99 upstream.

    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: damian
    Reported-by: Arnd Bergmann
    Signed-off-by: Josh Poimboeuf
    Acked-by: Peter Zijlstra (Intel)
    Cc: David Laight
    Cc: Greg KH
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Randy Dunlap
    Cc: Thomas Gleixner
    Link: http://lkml.kernel.org/r/0965e7fcfc5f31a276f0c7f298ff770c19b68706.1525923412.git.jpoimboe@redhat.com
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Josh Poimboeuf
     

12 Apr, 2018

1 commit

  • commit 3c1f05835cbf9fdfe60b81c718d82ceb94b6c55e upstream.

    Since the ORC unwinder was made the default on x86_64, Clang-built
    defconfig kernels have triggered some new objtool warnings:

    drivers/gpu/drm/i915/i915_gpu_error.o: warning: objtool: i915_error_printf()+0x6c: return with modified stack frame
    drivers/gpu/drm/i915/intel_display.o: warning: objtool: pipe_config_err()+0xa6: return with modified stack frame

    The problem is that objtool has never seen clang-built binaries before.

    Shockingly enough, objtool is apparently able to follow the code flow
    mostly fine, except for one instruction sequence. Instead of a LEAVE
    instruction, clang restores RSP and RBP the long way:

    67c: 48 89 ec mov %rbp,%rsp
    67f: 5d pop %rbp

    Teach objtool about this new code sequence.

    Reported-and-test-by: Matthias Kaehlcke
    Signed-off-by: Josh Poimboeuf
    Cc: Linus Torvalds
    Cc: Matthias Kaehlcke
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Link: http://lkml.kernel.org/r/fce88ce81c356eedcae7f00ed349cfaddb3363cc.1521741586.git.jpoimboe@redhat.com
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Josh Poimboeuf
     

15 Mar, 2018

5 commits

  • commit 63474dc4ac7ed3848a4786b9592dd061901f606d upstream.

    Fix the objtool build when cross-compiling a 64-bit kernel on a 32-bit
    host. This also simplifies read_retpoline_hints() a bit and makes its
    implementation similar to most of the other annotation reading
    functions.

    Reported-by: Sven Joachim
    Signed-off-by: Josh Poimboeuf
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Fixes: b5bc2231b8ad ("objtool: Add retpoline validation")
    Link: http://lkml.kernel.org/r/2ca46c636c23aa9c9d57d53c75de4ee3ddf7a7df.1520380691.git.jpoimboe@redhat.com
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Josh Poimboeuf
     
  • commit 1402fd8ed7e5bda1b3e7613b70780b0db392d1e6 upstream.

    Continue the switch table detection whack-a-mole. Add a check to
    distinguish KASAN data reads from switch data reads. The switch jump
    tables in .rodata have relocations associated with them.

    This fixes the following warning:

    crypto/asymmetric_keys/x509_cert_parser.o: warning: objtool: x509_note_pkey_algo()+0xa4: sibling call from callable instruction with modified stack frame

    Reported-by: Arnd Bergmann
    Signed-off-by: Josh Poimboeuf
    Signed-off-by: Thomas Gleixner
    Tested-by: Arnd Bergmann
    Cc: Peter Zijlstra
    Link: https://lkml.kernel.org/r/d7c8853022ad47d158cb81e953a40469fc08a95e.1519784382.git.jpoimboe@redhat.com
    Signed-off-by: Greg Kroah-Hartman

    Josh Poimboeuf
     
  • commit ca41b97ed9124fd62323a162de5852f6e28f94b8 upstream.

    David allowed retpolines in .init.text, except for modules, which will
    trip up objtool retpoline validation, fix that.

    Requested-by: David Woodhouse
    Signed-off-by: Peter Zijlstra (Intel)
    Acked-by: Thomas Gleixner
    Acked-by: Josh Poimboeuf
    Cc: Andy Lutomirski
    Cc: Arjan van de Ven
    Cc: Borislav Petkov
    Cc: Dan Williams
    Cc: Dave Hansen
    Cc: David Woodhouse
    Cc: Greg Kroah-Hartman
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Peter Zijlstra
     
  • commit b5bc2231b8ad4387c9641f235ca0ad8cd300b6df upstream.

    David requested a objtool validation pass for CONFIG_RETPOLINE=y enabled
    builds, where it validates no unannotated indirect jumps or calls are
    left.

    Add an additional .discard.retpoline_safe section to allow annotating
    the few indirect sites that are required and safe.

    Requested-by: David Woodhouse
    Signed-off-by: Peter Zijlstra (Intel)
    Reviewed-by: David Woodhouse
    Acked-by: Thomas Gleixner
    Acked-by: Josh Poimboeuf
    Cc: Andy Lutomirski
    Cc: Arjan van de Ven
    Cc: Borislav Petkov
    Cc: Dan Williams
    Cc: Dave Hansen
    Cc: Greg Kroah-Hartman
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Peter Zijlstra
     
  • commit 43a4525f80534530077683f6472d8971646b0ace upstream.

    Use the existing global variables instead of passing them around and
    creating duplicate global variables.

    Signed-off-by: Peter Zijlstra (Intel)
    Acked-by: Thomas Gleixner
    Acked-by: Josh Poimboeuf
    Cc: Andy Lutomirski
    Cc: Arjan van de Ven
    Cc: Borislav Petkov
    Cc: Dan Williams
    Cc: Dave Hansen
    Cc: David Woodhouse
    Cc: Greg Kroah-Hartman
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Peter Zijlstra
     

22 Feb, 2018

1 commit

  • commit fe24e27128252c230a34a6c628da2bf1676781ea upstream.

    Peter Zijlstra's patch for converting WARN() to use UD2 triggered a
    bunch of false "unreachable instruction" warnings, which then triggered
    a seg fault in ignore_unreachable_insn().

    The seg fault happened when it tried to dereference a NULL 'insn->func'
    pointer. Thanks to static_cpu_has(), some functions can jump to a
    non-function area in the .altinstr_aux section. That breaks
    ignore_unreachable_insn()'s assumption that it's always inside the
    original function.

    Make sure ignore_unreachable_insn() only follows jumps within the
    current function.

    Reported-by: Borislav Petkov
    Signed-off-by: Josh Poimboeuf
    Signed-off-by: Peter Zijlstra (Intel)
    Cc: Andy Lutomirski
    Cc: Arjan van de Ven
    Cc: Brian Gerst
    Cc: Denys Vlasenko
    Cc: H. Peter Anvin
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Cc: kbuild test robot
    Link: http://lkml.kernel.org/r/bace77a60d5af9b45eddb8f8fb9c776c8de657ef.1518130694.git.jpoimboe@redhat.com
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Josh Poimboeuf
     

17 Feb, 2018

1 commit

  • commit 99ce7962d52d1948ad6f2785e308d48e76e0a6ef upstream.

    Linus reported that GCC-7.3 generated a switch-table construct that
    confused objtool. It turns out that, in particular due to KASAN, it is
    possible to have unrelated .rodata usage in between the .rodata setup
    for the switch-table and the following indirect jump.

    The simple linear reverse search from the indirect jump would hit upon
    the KASAN .rodata usage first and fail to find a switch_table,
    resulting in a spurious 'sibling call with modified stack frame'
    warning.

    Fix this by creating a 'jump-stack' which we can 'unwind' during
    reversal, thereby skipping over much of the in-between code.

    This is not fool proof by any means, but is sufficient to make the
    known cases work. Future work would be to construct more comprehensive
    flow analysis code.

    Reported-and-tested-by: Linus Torvalds
    Signed-off-by: Peter Zijlstra (Intel)
    Acked-by: Josh Poimboeuf
    Cc: Borislav Petkov
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Link: http://lkml.kernel.org/r/20180208130232.GF25235@hirez.programming.kicks-ass.net
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Peter Zijlstra
     

08 Feb, 2018

3 commits

  • commit 830c1e3d16b2c1733cd1ec9c8f4d47a398ae31bc

    With the following fix:

    2a0098d70640 ("objtool: Fix seg fault with gold linker")

    ... a seg fault was avoided, but the original seg fault condition in
    objtool wasn't fixed. Replace the seg fault with an error message.

    Suggested-by: Ingo Molnar
    Signed-off-by: Josh Poimboeuf
    Cc: Andy Lutomirski
    Cc: Borislav Petkov
    Cc: Dave Hansen
    Cc: David Woodhouse
    Cc: Greg Kroah-Hartman
    Cc: Guenter Roeck
    Cc: H. Peter Anvin
    Cc: Juergen Gross
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Link: http://lkml.kernel.org/r/dc4585a70d6b975c99fc51d1957ccdde7bd52f3a.1517284349.git.jpoimboe@redhat.com
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Josh Poimboeuf
     
  • commit 17bc33914bcc98ba3c6b426fd1c49587a25c0597

    Now that the previous patch gave objtool the ability to read retpoline
    alternatives, it shows a new warning:

    arch/x86/entry/entry_64.o: warning: objtool: .entry_trampoline: don't know how to handle alternatives at end of section

    This is due to the JMP_NOSPEC in entry_SYSCALL_64_trampoline().

    Previously, objtool ignored this situation because it wasn't needed, and
    it would have required a bit of extra code. Now that this case exists,
    add proper support for it.

    Signed-off-by: Josh Poimboeuf
    Cc: Andy Lutomirski
    Cc: Borislav Petkov
    Cc: Dave Hansen
    Cc: David Woodhouse
    Cc: Greg Kroah-Hartman
    Cc: Guenter Roeck
    Cc: H. Peter Anvin
    Cc: Juergen Gross
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Link: http://lkml.kernel.org/r/2a30a3c2158af47d891a76e69bb1ef347e0443fd.1517284349.git.jpoimboe@redhat.com
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Josh Poimboeuf
     
  • commit a845c7cf4b4cb5e9e3b2823867892b27646f3a98

    Currently objtool requires all retpolines to be:

    a) patched in with alternatives; and

    b) annotated with ANNOTATE_NOSPEC_ALTERNATIVE.

    If you forget to do both of the above, objtool segfaults trying to
    dereference a NULL 'insn->call_dest' pointer.

    Avoid that situation and print a more helpful error message:

    quirks.o: warning: objtool: efi_delete_dummy_variable()+0x99: unsupported intra-function call
    quirks.o: warning: objtool: If this is a retpoline, please patch it in with alternatives and annotate it with ANNOTATE_NOSPEC_ALTERNATIVE.

    Future improvements can be made to make objtool smarter with respect to
    retpolines, but this is a good incremental improvement for now.

    Reported-and-tested-by: Guenter Roeck
    Signed-off-by: Josh Poimboeuf
    Cc: Andy Lutomirski
    Cc: Borislav Petkov
    Cc: Dave Hansen
    Cc: David Woodhouse
    Cc: Greg Kroah-Hartman
    Cc: H. Peter Anvin
    Cc: Juergen Gross
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Link: http://lkml.kernel.org/r/819e50b6d9c2e1a22e34c1a636c0b2057cc8c6e5.1517284349.git.jpoimboe@redhat.com
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Josh Poimboeuf
     

24 Jan, 2018

5 commits

  • commit 385d11b152c4eb638eeb769edcb3249533bb9a00 upstream.

    If a nonexistent file is supplied to objtool, it complains with a
    non-helpful error:

    open: No such file or directory

    Improve it to:

    objtool: Can't open 'foo': No such file or directory

    Reported-by: Markus
    Signed-off-by: Josh Poimboeuf
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Link: http://lkml.kernel.org/r/406a3d00a21225eee2819844048e17f68523ccf6.1516025651.git.jpoimboe@redhat.com
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Josh Poimboeuf
     
  • commit d89e426499cf36b96161bd32970d6783f1fbcb0e upstream.

    Fix a seg fault when no parameter is provided to 'objtool orc'.

    Signed-off-by: Simon Ser
    Signed-off-by: Josh Poimboeuf
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Link: http://lkml.kernel.org/r/9172803ec7ebb72535bcd0b7f966ae96d515968e.1514666459.git.jpoimboe@redhat.com
    Signed-off-by: Ingo Molnar
    Cc: Guenter Roeck
    Signed-off-by: Greg Kroah-Hartman

    Simon Ser
     
  • commit e7e83dd3ff1dd2f9e60213f6eedc7e5b08192062 upstream.

    Fix the following Clang enum conversion warning:

    arch/x86/decode.c:141:20: error: implicit conversion from enumeration
    type 'enum op_src_type' to different enumeration
    type 'enum op_dest_type' [-Werror,-Wenum-conversion]

    op->dest.type = OP_SRC_REG;
    ~ ^~~~~~~~~~

    It just happened to work before because OP_SRC_REG and OP_DEST_REG have
    the same value.

    Signed-off-by: Lukas Bulwahn
    Signed-off-by: Josh Poimboeuf
    Reviewed-by: Nicholas Mc Guire
    Reviewed-by: Nick Desaulniers
    Cc: Jiri Slaby
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Fixes: baa41469a7b9 ("objtool: Implement stack validation 2.0")
    Link: http://lkml.kernel.org/r/b4156c5738bae781c392e7a3691aed4514ebbdf2.1514323568.git.jpoimboe@redhat.com
    Signed-off-by: Ingo Molnar
    Cc: Guenter Roeck
    Signed-off-by: Greg Kroah-Hartman

    Lukas Bulwahn
     
  • commit ce90aaf5cde4ce057b297bb6c955caf16ef00ee6 upstream.

    Fix a seg fault which happens when an input file provided to 'objtool
    orc generate' doesn't have a '.shstrtab' section (for instance, object
    files produced by clang don't have this section).

    Signed-off-by: Simon Ser
    Signed-off-by: Josh Poimboeuf
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Link: http://lkml.kernel.org/r/c0f2231683e9bed40fac1f13ce2c33b8389854bc.1514666459.git.jpoimboe@redhat.com
    Signed-off-by: Ingo Molnar
    Cc: Guenter Roeck
    Signed-off-by: Greg Kroah-Hartman

    Simon Ser
     
  • commit 0f908ccbeca99ddf0ad60afa710e72aded4a5ea7 upstream.

    patch(1) loses the x bit. So if a user follows our patching
    instructions in Documentation/admin-guide/README.rst, their kernel will
    not compile.

    Fixes: 3bd51c5a371de ("objtool: Move kernel headers/code sync check to a script")
    Reported-by: Nicolas Bock
    Reported-by Joakim Tjernlund
    Cc: Ingo Molnar
    Cc: Josh Poimboeuf
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds
    Cc: Holger Hoffstätte
    Signed-off-by: Greg Kroah-Hartman

    Andrew Morton
     

17 Jan, 2018

2 commits

  • commit 258c76059cece01bebae098e81bacb1af2edad17 upstream.

    Getting objtool to understand retpolines is going to be a bit of a
    challenge. For now, take advantage of the fact that retpolines are
    patched in with alternatives. Just read the original (sane)
    non-alternative instruction, and ignore the patched-in retpoline.

    This allows objtool to understand the control flow *around* the
    retpoline, even if it can't yet follow what's inside. This means the
    ORC unwinder will fail to unwind from inside a retpoline, but will work
    fine otherwise.

    Signed-off-by: Josh Poimboeuf
    Signed-off-by: David Woodhouse
    Signed-off-by: Thomas Gleixner
    Cc: gnomes@lxorguk.ukuu.org.uk
    Cc: Rik van Riel
    Cc: Andi Kleen
    Cc: thomas.lendacky@amd.com
    Cc: Peter Zijlstra
    Cc: Linus Torvalds
    Cc: Jiri Kosina
    Cc: Andy Lutomirski
    Cc: Dave Hansen
    Cc: Kees Cook
    Cc: Tim Chen
    Cc: Greg Kroah-Hartman
    Cc: Paul Turner
    Link: https://lkml.kernel.org/r/1515707194-20531-3-git-send-email-dwmw@amazon.co.uk
    Signed-off-by: Greg Kroah-Hartman

    Josh Poimboeuf
     
  • commit 39b735332cb8b33a27c28592d969e4016c86c3ea upstream.

    A direct jump to a retpoline thunk is really an indirect jump in
    disguise. Change the objtool instruction type accordingly.

    Objtool needs to know where indirect branches are so it can detect
    switch statement jump tables.

    This fixes a bunch of warnings with CONFIG_RETPOLINE like:

    arch/x86/events/intel/uncore_nhmex.o: warning: objtool: nhmex_rbox_msr_enable_event()+0x44: sibling call from callable instruction with modified stack frame
    kernel/signal.o: warning: objtool: copy_siginfo_to_user()+0x91: sibling call from callable instruction with modified stack frame
    ...

    Signed-off-by: Josh Poimboeuf
    Signed-off-by: David Woodhouse
    Signed-off-by: Thomas Gleixner
    Cc: gnomes@lxorguk.ukuu.org.uk
    Cc: Rik van Riel
    Cc: Andi Kleen
    Cc: thomas.lendacky@amd.com
    Cc: Peter Zijlstra
    Cc: Linus Torvalds
    Cc: Jiri Kosina
    Cc: Andy Lutomirski
    Cc: Dave Hansen
    Cc: Kees Cook
    Cc: Tim Chen
    Cc: Greg Kroah-Hartman
    Cc: Paul Turner
    Link: https://lkml.kernel.org/r/1515707194-20531-2-git-send-email-dwmw@amazon.co.uk
    Signed-off-by: Greg Kroah-Hartman

    Josh Poimboeuf
     

30 Dec, 2017

6 commits

  • commit f5b5fab1780c98b74526dbac527574bd02dc16f8 upstream

    Update x86-opcode-map.txt based on the October 2017 Intel SDM publication.
    Fix INVPID to INVVPID.
    Add UD0 and UD1 instruction opcodes.

    Also sync the objtool and perf tooling copies of this file.

    Signed-off-by: Randy Dunlap
    Acked-by: Masami Hiramatsu
    Cc: Josh Poimboeuf
    Cc: Linus Torvalds
    Cc: Masami Hiramatsu
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Link: http://lkml.kernel.org/r/aac062d7-c0f6-96e3-5c92-ed299e2bd3da@infradead.org
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Randy Dunlap
     
  • commit 14c47b54b0d9389e3ca0718e805cdd90c5a4303a upstream.

    The new ORC unwinder breaks the build of a 64-bit kernel on a 32-bit
    host. Building the kernel on a i386 or x32 host fails with:

    orc_dump.c: In function 'orc_dump':
    orc_dump.c:105:26: error: passing argument 2 of 'elf_getshdrnum' from incompatible pointer type [-Werror=incompatible-pointer-types]
    if (elf_getshdrnum(elf, &nr_sections)) {
    ^
    In file included from /usr/local/include/gelf.h:32:0,
    from elf.h:22,
    from warn.h:26,
    from orc_dump.c:20:
    /usr/local/include/libelf.h:304:12: note: expected 'size_t * {aka unsigned int *}' but argument is of type 'long unsigned int *'
    extern int elf_getshdrnum (Elf *__elf, size_t *__dst);
    ^~~~~~~~~~~~~~
    orc_dump.c:190:17: error: format '%lx' expects argument of type 'long unsigned int', but argument 3 has type 'Elf64_Sxword {aka long long int}' [-Werror=format=]
    printf("%s+%lx:", name, rela.r_addend);
    ~~^ ~~~~~~~~~~~~~
    %llx

    Fix the build failure.

    Another problem is that if the user specifies HOSTCC or HOSTLD
    variables, they are ignored in the objtool makefile. Change the
    Makefile to respect these variables.

    Signed-off-by: Mikulas Patocka
    Signed-off-by: Josh Poimboeuf
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Sven Joachim
    Cc: Thomas Gleixner
    Fixes: 627fce14809b ("objtool: Add ORC unwind table generation")
    Link: http://lkml.kernel.org/r/19f0e64d8e07e30a7b307cd010eb780c404fe08d.1512252895.git.jpoimboe@redhat.com
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Mikulas Patocka
     
  • commit a356d2ae50790f49858ebed35da9e206336fafee upstream.

    objtool grew this new warning:

    Warning: synced file at 'tools/objtool/arch/x86/include/asm/inat.h' differs from latest kernel version at 'arch/x86/include/asm/inat.h'

    which upstream header grew new INAT_SEG_* definitions.

    Sync up the tooling version of the header.

    Reported-by: Linus Torvalds
    Cc: Josh Poimboeuf
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Ingo Molnar
     
  • commit 9eb719855f6c9b21eb5889d9ac2ca1c60527ad89 upstream.

    Stephen Rothwell reported this cross-compilation build failure:

    | In file included from orc_dump.c:19:0:
    | orc.h:21:10: fatal error: asm/orc_types.h: No such file or directory
    | ...

    Caused by:

    6a77cff819ae ("objtool: Move synced files to their original relative locations")

    Use the proper arch header files location, not the host-arch location.

    Bisected-by: Stephen Rothwell
    Reported-by: Stephen Rothwell
    Signed-off-by: Josh Poimboeuf
    Cc: Linus Torvalds
    Cc: Linux-Next Mailing List
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Link: http://lkml.kernel.org/r/20171108030152.bd76eahiwjwjt3kp@treble
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Josh Poimboeuf
     
  • commit 3bd51c5a371de917e4e7401c9df006b5998579df upstream.

    Replace the nasty diff checks in the objtool Makefile with a clean bash
    script, and make the warnings more specific.

    Heavily inspired by tools/perf/check-headers.sh.

    Suggested-by: Ingo Molnar
    Signed-off-by: Josh Poimboeuf
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Link: http://lkml.kernel.org/r/ab015f15ccd8c0c6008493c3c6ee3d495eaf2927.1509974346.git.jpoimboe@redhat.com
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Josh Poimboeuf
     
  • commit 6a77cff819ae3e31992bde6432c9b5720748a89b upstream.

    This will enable more straightforward comparisons, and it also makes the
    files 100% identical.

    Suggested-by: Ingo Molnar
    Signed-off-by: Josh Poimboeuf
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Link: http://lkml.kernel.org/r/407b2aaa317741f48fcf821592c0e96ab3be1890.1509974346.git.jpoimboe@redhat.com
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Josh Poimboeuf
     

25 Dec, 2017

2 commits

  • commit 6a93bb7e4a7d6670677d5b0eb980936eb9cc5d2e upstream.

    Print top-level objtool commands, along with the error on incorrect
    command line usage. Objtool command line parser exit's with code 129,
    for incorrect usage. Convert the cmd_usage() exit code also, to maintain
    consistency across objtool.

    After the patch:

    $ ./objtool -j

    Unknown option: -j

    usage: objtool COMMAND [ARGS]

    Commands:
    check Perform stack metadata validation on an object file
    orc Generate in-place ORC unwind tables for an object file

    $ echo $?
    129

    Signed-off-by: Kamalesh Babulal
    Acked-by: Josh Poimboeuf
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Link: http://lkml.kernel.org/r/1507992474-16142-1-git-send-email-kamalesh@linux.vnet.ibm.com
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Kamalesh Babulal
     
  • commit 00d96180dc38ef872ac471c2d3e14b067cbd895d upstream.

    If asm code specifies an UNWIND_HINT_EMPTY hint, don't warn if the
    section ends unexpectedly. This can happen with the xen-head.S code
    because the hypercall_page is "text" but it's all zeros.

    Signed-off-by: Josh Poimboeuf
    Cc: Andy Lutomirski
    Cc: Boris Ostrovsky
    Cc: Jiri Slaby
    Cc: Juergen Gross
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Link: http://lkml.kernel.org/r/ddafe199dd8797e40e3c2777373347eba1d65572.1505764066.git.jpoimboe@redhat.com
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Josh Poimboeuf
     

04 Nov, 2017

1 commit


02 Nov, 2017

1 commit

  • Many source files in the tree are missing licensing information, which
    makes it harder for compliance tools to determine the correct license.

    By default all files without license information are under the default
    license of the kernel, which is GPL version 2.

    Update the files which contain no license information with the 'GPL-2.0'
    SPDX license identifier. The SPDX identifier is a legally binding
    shorthand, which can be used instead of the full boiler plate text.

    This patch is based on work done by Thomas Gleixner and Kate Stewart and
    Philippe Ombredanne.

    How this work was done:

    Patches were generated and checked against linux-4.14-rc6 for a subset of
    the use cases:
    - file had no licensing information it it.
    - file was a */uapi/* one with no licensing information in it,
    - file was a */uapi/* one with existing licensing information,

    Further patches will be generated in subsequent months to fix up cases
    where non-standard license headers were used, and references to license
    had to be inferred by heuristics based on keywords.

    The analysis to determine which SPDX License Identifier to be applied to
    a file was done in a spreadsheet of side by side results from of the
    output of two independent scanners (ScanCode & Windriver) producing SPDX
    tag:value files created by Philippe Ombredanne. Philippe prepared the
    base worksheet, and did an initial spot review of a few 1000 files.

    The 4.13 kernel was the starting point of the analysis with 60,537 files
    assessed. Kate Stewart did a file by file comparison of the scanner
    results in the spreadsheet to determine which SPDX license identifier(s)
    to be applied to the file. She confirmed any determination that was not
    immediately clear with lawyers working with the Linux Foundation.

    Criteria used to select files for SPDX license identifier tagging was:
    - Files considered eligible had to be source code files.
    - Make and config files were included as candidates if they contained >5
    lines of source
    - File already had some variant of a license header in it (even if
    Reviewed-by: Philippe Ombredanne
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

20 Oct, 2017

1 commit

  • When an error occurs before adding an allocated insn to the list, free
    it before returning.

    Signed-off-by: Kamalesh Babulal
    Signed-off-by: Josh Poimboeuf
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Link: http://lkml.kernel.org/r/336da800bf6070eae11f4e0a3b9ca64c27658114.1508430423.git.jpoimboe@redhat.com
    Signed-off-by: Ingo Molnar

    Kamalesh Babulal
     

28 Sep, 2017

1 commit

  • Arnd Bergmann reported a bunch of warnings like:

    crypto/jitterentropy.o: warning: objtool: jent_fold_time()+0x3b: call without frame pointer save/setup
    crypto/jitterentropy.o: warning: objtool: jent_stuck()+0x1d: call without frame pointer save/setup
    crypto/jitterentropy.o: warning: objtool: jent_unbiased_bit()+0x15: call without frame pointer save/setup
    crypto/jitterentropy.o: warning: objtool: jent_read_entropy()+0x32: call without frame pointer save/setup
    crypto/jitterentropy.o: warning: objtool: jent_entropy_collector_free()+0x19: call without frame pointer save/setup

    and

    arch/x86/events/core.o: warning: objtool: collect_events uses BP as a scratch register
    arch/x86/events/core.o: warning: objtool: events_ht_sysfs_show()+0x22: call without frame pointer save/setup

    With certain rare configurations, GCC sometimes sets up the frame
    pointer with:

    lea (%rsp),%rbp

    instead of:

    mov %rsp,%rbp

    The instructions are equivalent, so treat the former like the latter.

    Reported-by: Arnd Bergmann
    Signed-off-by: Josh Poimboeuf
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Link: http://lkml.kernel.org/r/a468af8b28a69b83fffc6d7668be9b6fcc873699.1506526584.git.jpoimboe@redhat.com
    Signed-off-by: Ingo Molnar

    Josh Poimboeuf