aboutsummaryrefslogtreecommitdiff
path: root/tools/objtool
AgeCommit message (Collapse)AuthorFilesLines
2020-05-15objtool: use gelf_getsymshndx to handle >64k sectionsSami Tolvanen1-7/+17
Currently, objtool fails to load the correct section for symbols when the index is greater than SHN_LORESERVE. Use gelf_getsymshndx instead of gelf_getsym to handle >64k sections. Signed-off-by: Sami Tolvanen <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Kees Cook <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2020-05-15objtool: Allow no-op CFI ops in alternativesPeter Zijlstra1-5/+6
Randy reported a false-positive: arch/x86/hyperv/hv_apic.o: warning: objtool: hv_apic_write()+0x25: alternative modifies stack What happens is that: alternative_io("movl %0, %P1", "xchgl %0, %P1", X86_BUG_11AP, 13d: 89 9d 00 d0 7f ff mov %ebx,-0x803000(%rbp) decodes to an instruction with CFI-ops because it modifies RBP. However, due to this being a !frame-pointer build, that should not in fact change the CFI state. So instead of dis-allowing any CFI-op, verify the op would've actually changed the CFI state. Fixes: 7117f16bf460 ("objtool: Fix ORC vs alternatives") Reported-by: Randy Dunlap <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Acked-by: Josh Poimboeuf <[email protected]> Acked-by: Randy Dunlap <[email protected]> Tested-by: Randy Dunlap <[email protected]>
2020-05-10Merge tag 'x86-urgent-2020-05-10' of ↵Linus Torvalds2-4/+5
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Thomas Gleixner: "A set of fixes for x86: - Ensure that direct mapping alias is always flushed when changing page attributes. The optimization for small ranges failed to do so when the virtual address was in the vmalloc or module space. - Unbreak the trace event registration for syscalls without arguments caused by the refactoring of the SYSCALL_DEFINE0() macro. - Move the printk in the TSC deadline timer code to a place where it is guaranteed to only be called once during boot and cannot be rearmed by clearing warn_once after boot. If it's invoked post boot then lockdep rightfully complains about a potential deadlock as the calling context is different. - A series of fixes for objtool and the ORC unwinder addressing variety of small issues: - Stack offset tracking for indirect CFAs in objtool ignored subsequent pushs and pops - Repair the unwind hints in the register clearing entry ASM code - Make the unwinding in the low level exit to usermode code stop after switching to the trampoline stack. The unwind hint is no longer valid and the ORC unwinder emits a warning as it can't find the registers anymore. - Fix unwind hints in switch_to_asm() and rewind_stack_do_exit() which caused objtool to generate bogus ORC data. - Prevent unwinder warnings when dumping the stack of a non-current task as there is no way to be sure about the validity because the dumped stack can be a moving target. - Make the ORC unwinder behave the same way as the frame pointer unwinder when dumping an inactive tasks stack and do not skip the first frame. - Prevent ORC unwinding before ORC data has been initialized - Immediately terminate unwinding when a unknown ORC entry type is found. - Prevent premature stop of the unwinder caused by IRET frames. - Fix another infinite loop in objtool caused by a negative offset which was not catched. - Address a few build warnings in the ORC unwinder and add missing static/ro_after_init annotations" * tag 'x86-urgent-2020-05-10' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/unwind/orc: Move ORC sorting variables under !CONFIG_MODULES x86/apic: Move TSC deadline timer debug printk ftrace/x86: Fix trace event registration for syscalls without arguments x86/mm/cpa: Flush direct map alias during cpa objtool: Fix infinite loop in for_offset_range() x86/unwind/orc: Fix premature unwind stoppage due to IRET frames x86/unwind/orc: Fix error path for bad ORC entry type x86/unwind/orc: Prevent unwinding before ORC initialization x86/unwind/orc: Don't skip the first frame for inactive tasks x86/unwind: Prevent false warnings for non-current tasks x86/unwind/orc: Convert global variables to static x86/entry/64: Fix unwind hints in rewind_stack_do_exit() x86/entry/64: Fix unwind hints in __switch_to_asm() x86/entry/64: Fix unwind hints in kernel exit path x86/entry/64: Fix unwind hints in register clearing code objtool: Fix stack offset tracking for indirect CFAs
2020-05-08Merge branch 'kcsan-for-tip' of ↵Thomas Gleixner1-0/+4
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu into locking/kcsan Pull KCSAN updates from Paul McKenney.
2020-05-07objtool: Fix infinite loop in find_jump_table()Josh Poimboeuf1-2/+13
Kristen found a hang in objtool when building with -ffunction-sections. It was caused by evergreen_pcie_gen2_enable.cold() being laid out immediately before evergreen_pcie_gen2_enable(). Since their "pfunc" is always the same, find_jump_table() got into an infinite loop because it didn't recognize the boundary between the two functions. Fix that with a new prev_insn_same_sym() helper, which doesn't cross subfunction boundaries. Reported-by: Kristen Carlson Accardi <[email protected]> Signed-off-by: Josh Poimboeuf <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Link: https://lkml.kernel.org/r/378b51c9d9c894dc3294bc460b4b0869e950b7c5.1588110291.git.jpoimboe@redhat.com
2020-05-06objtool, kcsan: Add kcsan_disable_current() and kcsan_enable_current_nowarn()Marco Elver1-0/+2
Both are safe to be called from uaccess contexts. Signed-off-by: Marco Elver <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]>
2020-04-30objtool: Add support for intra-function callsAlexandre Chartre3-4/+91
Change objtool to support intra-function calls. On x86, an intra-function call is represented in objtool as a push onto the stack (of the return address), and a jump to the destination address. That way the stack information is correctly updated and the call flow is still accurate. Signed-off-by: Alexandre Chartre <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Miroslav Benes <[email protected]> Acked-by: Josh Poimboeuf <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2020-04-30objtool: Move the IRET hack into the arch decoderMiroslav Benes5-25/+21
Quoting Julien: "And the other suggestion is my other email was that you don't even need to add INSN_EXCEPTION_RETURN. You can keep IRET as INSN_CONTEXT_SWITCH by default and x86 decoder lookups the symbol conaining an iret. If it's a function symbol, it can just set the type to INSN_OTHER so that it caries on to the next instruction after having handled the stack_op." Suggested-by: Julien Thierry <[email protected]> Signed-off-by: Miroslav Benes <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Miroslav Benes <[email protected]> Acked-by: Josh Poimboeuf <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2020-04-30objtool: Remove INSN_STACKPeter Zijlstra3-27/+0
With the unconditional use of handle_insn_ops(), INSN_STACK has lost its purpose. Remove it. Suggested-by: Julien Thierry <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Miroslav Benes <[email protected]> Acked-by: Josh Poimboeuf <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2020-04-30objtool: Make handle_insn_ops() unconditionalPeter Zijlstra1-5/+3
Now that every instruction has a list of stack_ops; we can trivially distinquish those instructions that do not have stack_ops, their list is empty. This means we can now call handle_insn_ops() unconditionally. Suggested-by: Julien Thierry <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Miroslav Benes <[email protected]> Acked-by: Josh Poimboeuf <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2020-04-30objtool: Rework allocating stack_ops on decodePeter Zijlstra1-104/+147
Wrap each stack_op in a macro that allocates and adds it to the list. This simplifies trying to figure out what to do with the pre-allocated stack_op at the end. Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Alexandre Chartre <[email protected]> Reviewed-by: Miroslav Benes <[email protected]> Acked-by: Josh Poimboeuf <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2020-04-30objtool: UNWIND_HINT_RET_OFFSET should not check registersAlexandre Chartre1-0/+8
UNWIND_HINT_RET_OFFSET will adjust a modified stack. However if a callee-saved register was pushed on the stack then the stack frame will still appear modified. So stop checking registers when UNWIND_HINT_RET_OFFSET is used. Signed-off-by: Alexandre Chartre <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Miroslav Benes <[email protected]> Acked-by: Josh Poimboeuf <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2020-04-30objtool: is_fentry_call() crashes if call has no destinationAlexandre Chartre1-1/+1
Fix is_fentry_call() so that it works if a call has no destination set (call_dest). This needs to be done in order to support intra- function calls. Signed-off-by: Alexandre Chartre <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Miroslav Benes <[email protected]> Acked-by: Josh Poimboeuf <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2020-04-30objtool: Fix ORC vs alternativesPeter Zijlstra2-1/+40
Jann reported that (for instance) entry_64.o:general_protection has very odd ORC data: 0000000000000f40 <general_protection>: #######sp:sp+8 bp:(und) type:iret end:0 f40: 90 nop #######sp:(und) bp:(und) type:call end:0 f41: 90 nop f42: 90 nop #######sp:sp+8 bp:(und) type:iret end:0 f43: e8 a8 01 00 00 callq 10f0 <error_entry> #######sp:sp+0 bp:(und) type:regs end:0 f48: f6 84 24 88 00 00 00 testb $0x3,0x88(%rsp) f4f: 03 f50: 74 00 je f52 <general_protection+0x12> f52: 48 89 e7 mov %rsp,%rdi f55: 48 8b 74 24 78 mov 0x78(%rsp),%rsi f5a: 48 c7 44 24 78 ff ff movq $0xffffffffffffffff,0x78(%rsp) f61: ff ff f63: e8 00 00 00 00 callq f68 <general_protection+0x28> f68: e9 73 02 00 00 jmpq 11e0 <error_exit> #######sp:(und) bp:(und) type:call end:0 f6d: 0f 1f 00 nopl (%rax) Note the entry at 0xf41. Josh found this was the result of commit: 764eef4b109a ("objtool: Rewrite alt->skip_orig") Due to the early return in validate_branch() we no longer set insn->cfi of the original instruction stream (the NOPs at 0xf41 and 0xf42) and we'll end up with the above weirdness. In other discussions we realized alternatives should be ORC invariant; that is, due to there being only a single ORC table, it must be valid for all alternatives. The easiest way to ensure this is to not allow any stack modifications in alternatives. When we enforce this latter observation, we get the property that the whole alternative must have the same CFI, which we can employ to fix the former report. Fixes: 764eef4b109a ("objtool: Rewrite alt->skip_orig") Reported-by: Jann Horn <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Miroslav Benes <[email protected]> Acked-by: Josh Poimboeuf <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2020-04-30objtool: Uniquely identify alternative instruction groupsAlexandre Chartre2-2/+7
Assign a unique identifier to every alternative instruction group in order to be able to tell which instructions belong to what alternative. [peterz: extracted from a larger patch] Signed-off-by: Alexandre Chartre <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Miroslav Benes <[email protected]>
2020-04-30objtool: Remove check preventing branches within alternativeJulien Thierry1-6/+0
While jumping from outside an alternative region to the middle of an alternative region is very likely wrong, jumping from an alternative region into the same region is valid. It is a common pattern on arm64. The first pattern is unlikely to happen in practice and checking only for this adds a lot of complexity. Just remove the current check. Suggested-by: Josh Poimboeuf <[email protected]> Signed-off-by: Julien Thierry <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Miroslav Benes <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2020-04-26objtool: Fix infinite loop in for_offset_range()Josh Poimboeuf1-3/+4
Randy reported that objtool got stuck in an infinite loop when processing drivers/i2c/busses/i2c-parport.o. It was caused by the following code: 00000000000001fd <line_set>: 1fd: 48 b8 00 00 00 00 00 movabs $0x0,%rax 204: 00 00 00 1ff: R_X86_64_64 .rodata-0x8 207: 41 55 push %r13 209: 41 89 f5 mov %esi,%r13d 20c: 41 54 push %r12 20e: 49 89 fc mov %rdi,%r12 211: 55 push %rbp 212: 48 89 d5 mov %rdx,%rbp 215: 53 push %rbx 216: 0f b6 5a 01 movzbl 0x1(%rdx),%ebx 21a: 48 8d 34 dd 00 00 00 lea 0x0(,%rbx,8),%rsi 221: 00 21e: R_X86_64_32S .rodata 222: 48 89 f1 mov %rsi,%rcx 225: 48 29 c1 sub %rax,%rcx find_jump_table() saw the .rodata reference and tried to find a jump table associated with it (though there wasn't one). The -0x8 rela addend is unusual. It caused find_jump_table() to send a negative table_offset (unsigned 0xfffffffffffffff8) to find_rela_by_dest(). The negative offset should have been harmless, but it actually threw for_offset_range() for a loop... literally. When the mask value got incremented past the end value, it also wrapped to zero, causing the loop exit condition to remain true forever. Prevent this scenario from happening by ensuring the incremented value is always >= the starting value. Fixes: 74b873e49d92 ("objtool: Optimize find_rela_by_dest_range()") Reported-by: Randy Dunlap <[email protected]> Tested-by: Randy Dunlap <[email protected]> Acked-by: Randy Dunlap <[email protected]> Signed-off-by: Josh Poimboeuf <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Cc: Julien Thierry <[email protected]> Cc: Miroslav Benes <[email protected]> Cc: Peter Zijlstra <[email protected]> Link: https://lore.kernel.org/r/02b719674b031800b61e33c30b2e823183627c19.1587842122.git.jpoimboe@redhat.com
2020-04-25objtool: Fix stack offset tracking for indirect CFAsJosh Poimboeuf1-1/+1
When the current frame address (CFA) is stored on the stack (i.e., cfa->base == CFI_SP_INDIRECT), objtool neglects to adjust the stack offset when there are subsequent pushes or pops. This results in bad ORC data at the end of the ENTER_IRQ_STACK macro, when it puts the previous stack pointer on the stack and does a subsequent push. This fixes the following unwinder warning: WARNING: can't dereference registers at 00000000f0a6bdba for ip interrupt_entry+0x9f/0xa0 Fixes: 627fce14809b ("objtool: Add ORC unwind table generation") Reported-by: Vince Weaver <[email protected]> Reported-by: Dave Jones <[email protected]> Reported-by: Steven Rostedt <[email protected]> Reported-by: Vegard Nossum <[email protected]> Reported-by: Joe Mario <[email protected]> Reviewed-by: Miroslav Benes <[email protected]> Signed-off-by: Josh Poimboeuf <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Jann Horn <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: https://lore.kernel.org/r/853d5d691b29e250333332f09b8e27410b2d9924.1587808742.git.jpoimboe@redhat.com
2020-04-23objtool: Constify arch_decode_instruction()Ingo Molnar2-4/+4
Mostly straightforward constification, except that WARN_FUNC() needs a writable pointer while we have read-only pointers, so deflect this to WARN(). Acked-by: Josh Poimboeuf <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Sami Tolvanen <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-04-23objtool: Rename elf_read() to elf_open_read()Ingo Molnar3-3/+3
'struct elf *' handling is an open/close paradigm, make sure the naming matches that: elf_open_read() elf_write() elf_close() Acked-by: Josh Poimboeuf <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Sami Tolvanen <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-04-23objtool: Constify 'struct elf *' parametersIngo Molnar2-15/+15
In preparation to parallelize certain parts of objtool, map out which uses of various data structures are read-only vs. read-write. As a first step constify 'struct elf' pointer passing, most of the secondary uses of it in find_symbol_*() methods are read-only. Also, while at it, better group the 'struct elf' handling methods in elf.h. Acked-by: Josh Poimboeuf <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Sami Tolvanen <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-04-22objtool: Fix off-by-one in symbol_by_offset()Julien Thierry1-1/+1
Sometimes, WARN_FUNC() and other users of symbol_by_offset() will associate the first instruction of a symbol with the symbol preceding it. This is because symbol->offset + symbol->len is already outside of the symbol's range. Fixes: 2a362ecc3ec9 ("objtool: Optimize find_symbol_*() and read_symbols()") Signed-off-by: Julien Thierry <[email protected]> Reviewed-by: Miroslav Benes <[email protected]> Signed-off-by: Josh Poimboeuf <[email protected]>
2020-04-22objtool: Fix 32bit cross buildsPeter Zijlstra1-1/+1
Apparently there's people doing 64bit builds on 32bit machines. Fixes: 74b873e49d92 ("objtool: Optimize find_rela_by_dest_range()") Reported-by: [email protected] Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
2020-04-22objtool: Also consider .entry.text as noinstrThomas Gleixner1-6/+12
Consider all of .entry.text as noinstr. This gets us coverage across the PTI boundary. While we could add everything .noinstr.text into .entry.text that would bloat the amount of code in the user mapping. Signed-off-by: Thomas Gleixner <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Miroslav Benes <[email protected]> Reviewed-by: Alexandre Chartre <[email protected]> Acked-by: Josh Poimboeuf <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2020-04-22objtool: Add STT_NOTYPE noinstr validationPeter Zijlstra1-16/+30
Make sure to also check STT_NOTYPE symbols for noinstr violations. Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Miroslav Benes <[email protected]> Reviewed-by: Alexandre Chartre <[email protected]> Acked-by: Josh Poimboeuf <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2020-04-22objtool: Rearrange validate_section()Peter Zijlstra1-22/+29
In preparation of further changes, once again break out the loop body. No functional changes intended. Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Miroslav Benes <[email protected]> Reviewed-by: Alexandre Chartre <[email protected]> Acked-by: Josh Poimboeuf <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2020-04-22objtool: Avoid iterating !text section symbolsPeter Zijlstra1-1/+5
validate_functions() iterates all sections their symbols; this is pointless to do for !text sections as they won't have instructions anyway. Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Miroslav Benes <[email protected]> Reviewed-by: Alexandre Chartre <[email protected]> Acked-by: Josh Poimboeuf <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2020-04-22objtool: Use sec_offset_hash() for insn_hashPeter Zijlstra1-2/+3
In preparation for find_insn_containing(), change insn_hash to use sec_offset_hash(). This actually reduces runtime; probably because mixing in the section index reduces the collisions due to text sections all starting their instructions at offset 0. Runtime on vmlinux.o from 3.1 to 2.5 seconds. Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Miroslav Benes <[email protected]> Reviewed-by: Alexandre Chartre <[email protected]> Acked-by: Josh Poimboeuf <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2020-04-22objtool: Optimize !vmlinux.o againPeter Zijlstra3-26/+52
When doing kbuild tests to see if the objtool changes affected those I found that there was a measurable regression: pre post real 1m13.594 1m16.488s user 34m58.246s 35m23.947s sys 4m0.393s 4m27.312s Perf showed that for small files the increased hash-table sizes were a measurable difference. Since we already have -l "vmlinux" to distinguish between the modes, make it also use a smaller portion of the hash-tables. This flips it into a small win: real 1m14.143s user 34m49.292s sys 3m44.746s Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Miroslav Benes <[email protected]> Reviewed-by: Alexandre Chartre <[email protected]> Acked-by: Josh Poimboeuf <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2020-04-22objtool: Implement noinstr validationPeter Zijlstra5-4/+112
Validate that any call out of .noinstr.text is in between instr_begin() and instr_end() annotations. This annotation is useful to ensure correct behaviour wrt tracing sensitive code like entry/exit and idle code. When we run code in a sensitive context we want a guarantee no unknown code is ran. Since this validation relies on knowing the section of call destination symbols, we must run it on vmlinux.o instead of on individual object files. Add two options: -d/--duplicate "duplicate validation for vmlinux" -l/--vmlinux "vmlinux.o validation" Where the latter auto-detects when objname ends with "vmlinux.o" and the former will force all validations, also those already done on !vmlinux object files. Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Miroslav Benes <[email protected]> Reviewed-by: Alexandre Chartre <[email protected]> Acked-by: Josh Poimboeuf <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2020-04-22objtool: Fix !CFI insn_state propagationPeter Zijlstra4-140/+157
Objtool keeps per instruction CFI state in struct insn_state and will save/restore this where required. However, insn_state has grown some !CFI state, and this must not be saved/restored (that would loose/destroy state). Fix this by moving the CFI specific parts of insn_state into struct cfi_state. Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Miroslav Benes <[email protected]> Reviewed-by: Alexandre Chartre <[email protected]> Acked-by: Josh Poimboeuf <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2020-04-22objtool: Rename struct cfi_statePeter Zijlstra4-4/+4
There's going to be a new struct cfi_state, rename this one to make place. Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Miroslav Benes <[email protected]> Reviewed-by: Alexandre Chartre <[email protected]> Acked-by: Josh Poimboeuf <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2020-04-22objtool: Remove SAVE/RESTORE hintsPeter Zijlstra2-40/+4
The SAVE/RESTORE hints are now unused; remove them. Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Miroslav Benes <[email protected]> Reviewed-by: Alexandre Chartre <[email protected]> Acked-by: Josh Poimboeuf <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2020-04-22objtool: Introduce HINT_RET_OFFSETPeter Zijlstra2-9/+19
Normally objtool ensures a function keeps the stack layout invariant. But there is a useful exception, it is possible to stuff the return stack in order to 'inject' a 'call': push $fun ret In this case the invariant mentioned above is violated. Add an objtool HINT to annotate this and allow a function exit with a modified stack frame. Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Miroslav Benes <[email protected]> Reviewed-by: Alexandre Chartre <[email protected]> Acked-by: Josh Poimboeuf <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2020-04-22objtool: Better handle IRETPeter Zijlstra3-15/+29
Teach objtool a little more about IRET so that we can avoid using the SAVE/RESTORE annotation. In particular, make the weird corner case in insn->restore go away. The purpose of that corner case is to deal with the fact that UNWIND_HINT_RESTORE lands on the instruction after IRET, but that instruction can end up being outside the basic block, consider: if (cond) sync_core() foo(); Then the hint will land on foo(), and we'll encounter the restore hint without ever having seen the save hint. By teaching objtool about the arch specific exception frame size, and assuming that any IRET in an STT_FUNC symbol is an exception frame sized POP, we can remove the use of save/restore hints for this code. Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Miroslav Benes <[email protected]> Reviewed-by: Alexandre Chartre <[email protected]> Acked-by: Josh Poimboeuf <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2020-04-22objtool: Support multiple stack_op per instructionJulien Thierry4-31/+62
Instruction sets can include more or less complex operations which might not fit the currently defined set of stack_ops. Combining more than one stack_op provides more flexibility to describe the behaviour of an instruction. This also reduces the need to define new stack_ops specific to a single instruction set. Allow instruction decoders to generate multiple stack_op per instruction. Signed-off-by: Julien Thierry <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Miroslav Benes <[email protected]> Reviewed-by: Alexandre Chartre <[email protected]> Acked-by: Josh Poimboeuf <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2020-04-22objtool: Remove redundant .rodata section name comparisonMuchun Song1-2/+2
If the prefix of section name is not '.rodata', the following function call can never return 0. strcmp(sec->name, C_JUMP_TABLE_SECTION) So the name comparison is pointless, just remove it. Signed-off-by: Muchun Song <[email protected]> Signed-off-by: Josh Poimboeuf <[email protected]> Signed-off-by: Ingo Molnar <[email protected]>
2020-04-22objtool: Documentation: document UACCESS warningsNick Desaulniers1-0/+26
Compiling with Clang and CONFIG_KASAN=y was exposing a few warnings: call to memset() with UACCESS enabled Document how to fix these for future travelers. Link: https://github.com/ClangBuiltLinux/linux/issues/876 Suggested-by: Kamalesh Babulal <[email protected]> Suggested-by: Matt Helsley <[email protected]> Suggested-by: Peter Zijlstra <[email protected]> Suggested-by: Randy Dunlap <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> Signed-off-by: Josh Poimboeuf <[email protected]> Signed-off-by: Ingo Molnar <[email protected]>
2020-04-22objtool: Split out arch-specific CFI definitionsJulien Thierry3-20/+29
Some CFI definitions used by generic objtool code have no reason to vary from one architecture to another. Keep those definitions in generic code and move the arch-specific ones to a new arch-specific header. Signed-off-by: Julien Thierry <[email protected]> Acked-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Miroslav Benes <[email protected]> Signed-off-by: Josh Poimboeuf <[email protected]> Signed-off-by: Ingo Molnar <[email protected]>
2020-04-22objtool: Add abstraction for destination offsetsRaphael Gault3-8/+27
The jump and call destination relocation offsets are x86-specific. Abstract them by calling arch-specific implementations. [ jthierry: Remove superfluous comment; replace other addend offsets with arch_dest_rela_offset() ] Signed-off-by: Raphael Gault <[email protected]> Signed-off-by: Julien Thierry <[email protected]> Acked-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Miroslav Benes <[email protected]> Signed-off-by: Josh Poimboeuf <[email protected]> Signed-off-by: Ingo Molnar <[email protected]>
2020-04-22objtool: Use arch specific values in restore_reg()Julien Thierry1-2/+2
The initial register state is set up by arch specific code. Use the value the arch code has set when restoring registers from the stack. Suggested-by: Raphael Gault <[email protected]> Signed-off-by: Julien Thierry <[email protected]> Acked-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Miroslav Benes <[email protected]> Signed-off-by: Josh Poimboeuf <[email protected]> Signed-off-by: Ingo Molnar <[email protected]>
2020-04-22objtool: Ignore empty alternativesJulien Thierry1-0/+6
The .alternatives section can contain entries with no original instructions. Objtool will currently crash when handling such an entry. Just skip that entry, but still give a warning to discourage useless entries. Signed-off-by: Julien Thierry <[email protected]> Acked-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Miroslav Benes <[email protected]> Signed-off-by: Josh Poimboeuf <[email protected]> Signed-off-by: Ingo Molnar <[email protected]>
2020-04-22objtool: Clean instruction state before each function validationJulien Thierry1-7/+6
When a function fails its validation, it might leave a stale state that will be used for the validation of other functions. That would cause false warnings on potentially valid functions. Reset the instruction state before the validation of each individual function. Signed-off-by: Julien Thierry <[email protected]> Acked-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Miroslav Benes <[email protected]> Signed-off-by: Josh Poimboeuf <[email protected]> Signed-off-by: Ingo Molnar <[email protected]>
2020-04-22objtool: Remove redundant checks on operand typeJulien Thierry1-3/+1
POP operations are already in the code path where the destination operand is OP_DEST_REG. There is no need to check the operand type again. Signed-off-by: Julien Thierry <[email protected]> Acked-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Miroslav Benes <[email protected]> Signed-off-by: Josh Poimboeuf <[email protected]> Signed-off-by: Ingo Molnar <[email protected]>
2020-04-22objtool: Always do header sync checkJulien Thierry1-1/+1
Currently, the check of tools files against kernel equivalent is only done after every object file has been built. This means one might fix build issues against outdated headers without seeing a warning about this. Check headers before any object is built. Also, make it part of a FORCE'd recipe so every attempt to build objtool will report the outdated headers (if any). Signed-off-by: Julien Thierry <[email protected]> Acked-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Miroslav Benes <[email protected]> Signed-off-by: Josh Poimboeuf <[email protected]> Signed-off-by: Ingo Molnar <[email protected]>
2020-04-22objtool: Fix off-by-one in symbol_by_offset()Julien Thierry1-1/+1
Sometimes, WARN_FUNC() and other users of symbol_by_offset() will associate the first instruction of a symbol with the symbol preceding it. This is because symbol->offset + symbol->len is already outside of the symbol's range. Fixes: 2a362ecc3ec9 ("objtool: Optimize find_symbol_*() and read_symbols()") Signed-off-by: Julien Thierry <[email protected]> Reviewed-by: Miroslav Benes <[email protected]> Signed-off-by: Josh Poimboeuf <[email protected]> Signed-off-by: Ingo Molnar <[email protected]>
2020-04-22objtool: Fix 32bit cross buildsPeter Zijlstra1-1/+1
Apparently there's people doing 64bit builds on 32bit machines. Fixes: 74b873e49d92 ("objtool: Optimize find_rela_by_dest_range()") Reported-by: [email protected] Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Signed-off-by: Ingo Molnar <[email protected]>
2020-04-14objtool: Make BP scratch register warning more robustJosh Poimboeuf1-2/+2
If func is NULL, a seg fault can result. This is a theoretical issue which was found by Coverity, ID: 1492002 ("Dereference after null check"). Fixes: c705cecc8431 ("objtool: Track original function across branches") Reported-by: Gustavo A. R. Silva <[email protected]> Signed-off-by: Josh Poimboeuf <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Link: https://lkml.kernel.org/r/afc628693a37acd287e843bcc5c0430263d93c74.1585761021.git.jpoimboe@redhat.com
2020-04-14objtool: Fix switch table detection in .text.unlikelyJosh Poimboeuf1-4/+1
If a switch jump table's indirect branch is in a ".cold" subfunction in .text.unlikely, objtool doesn't detect it, and instead prints a false warning: drivers/media/v4l2-core/v4l2-ioctl.o: warning: objtool: v4l_print_format.cold()+0xd6: sibling call from callable instruction with modified stack frame drivers/hwmon/max6650.o: warning: objtool: max6650_probe.cold()+0xa5: sibling call from callable instruction with modified stack frame drivers/media/dvb-frontends/drxk_hard.o: warning: objtool: init_drxk.cold()+0x16f: sibling call from callable instruction with modified stack frame Fix it by comparing the function, instead of the section and offset. Fixes: 13810435b9a7 ("objtool: Support GCC 8's cold subfunctions") Signed-off-by: Josh Poimboeuf <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Reviewed-by: Miroslav Benes <[email protected]> Acked-by: Peter Zijlstra (Intel) <[email protected]> Link: https://lkml.kernel.org/r/157c35d42ca9b6354bbb1604fe9ad7d1153ccb21.1585761021.git.jpoimboe@redhat.com
2020-04-14objtool: Support Clang non-section symbols in ORC generationJosh Poimboeuf1-7/+26
When compiling the kernel with AS=clang, objtool produces a lot of warnings: warning: objtool: missing symbol for section .text warning: objtool: missing symbol for section .init.text warning: objtool: missing symbol for section .ref.text It then fails to generate the ORC table. The problem is that objtool assumes text section symbols always exist. But the Clang assembler is aggressive about removing them. When generating relocations for the ORC table, objtool always tries to reference instructions by their section symbol offset. If the section symbol doesn't exist, it bails. Do a fallback: when a section symbol isn't available, reference a function symbol instead. Reported-by: Dmitry Golovin <[email protected]> Signed-off-by: Josh Poimboeuf <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Reviewed-by: Miroslav Benes <[email protected]> Acked-by: Peter Zijlstra (Intel) <[email protected]> Link: https://github.com/ClangBuiltLinux/linux/issues/669 Link: https://lkml.kernel.org/r/9a9cae7fcf628843aabe5a086b1a3c5bf50f42e8.1585761021.git.jpoimboe@redhat.com
Powered by cgit, Gruvboxed by Blaster4385.