Select Git revision
Search by author
- Any Author
- authors
-
72162444 72162444 gaochangning
-
Aakash Dave aakash.dave
-
Aaron Kim akim
-
Aaron Kloc akloc
-
Aaron Lan aaron.lan
-
Aaron Nabil aaronna
-
Aaron Pohle aaron.pohle
-
Abbott Chung chung.abbott
-
Abdallah Omar abdallah_omar
-
Abdessamii Chalbi abdessamii.chalbi
-
Abdul Hussain Sirajudeen abdul.hussain
-
Abdullah Alghamdi a.alghamdi
-
Abdullah Elmarghany abdullah_elmarghany
-
Abel Fang abel_fang
-
Abhijeet Badurkar abhijeet.badurkar
-
Abhijit Adsule adsule
-
Abhijit Murthy abhijit
-
Abhi Khanal akhanal
-
Abhilash Sahoo abhilashsahoo
-
Abhimanyu Raj abhimanyu.raj
- Jul 29, 2022
-
-
Waiman Long authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2090231 Conflcits: Fuzz in arch/x86/xen/xen-asm.S due to missing upstream commit 09c41307 ("x86/xen: Make irq_disable() noinstr"). commit 5c8f6a2e Author: Lai Jiangshan <laijs@linux.alibaba.com> Date: Fri, 26 Nov 2021 18:11:23 +0800 x86/xen: Add xenpv_restore_regs_and_return_to_usermode() In the native case, PER_CPU_VAR(cpu_tss_rw + TSS_sp0) is the trampoline stack. But XEN pv doesn't use trampoline stack, so PER_CPU_VAR(cpu_tss_rw + TSS_sp0) is also the kernel stack. In that case, source and destination stacks are identical, which means that reusing swapgs_restore_regs_and_return_to_usermode() in XEN pv would cause %rsp to move up to the top of the kernel stack and leave the IRET frame below %rsp. This is dangerous as it can be corrupted if #NMI / #MC hit as either of these events occurring in the middle of the stack pushing would clobber data on the (original) stack. And, with XEN pv, swapgs_restore_regs_and_return_to_usermode() pushing the IRET frame on to the original address is useless and error-prone when there is any future attempt to modify the code. [ bp: Massage commit message. ] Fixes: 7f2590a1 ("x86/entry/64: Use a per-CPU trampoline stack for IDT entries") Signed-off-by:
Lai Jiangshan <laijs@linux.alibaba.com> Signed-off-by:
Borislav Petkov <bp@suse.de> Reviewed-by:
Boris Ostrovsky <boris.ostrovsky@oracle.com> Link: https://lkml.kernel.org/r/20211126101209.8613-4-jiangshanlai@gmail.com Signed-off-by:
Waiman Long <longman@redhat.com>
-
Waiman Long authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2090231 commit 1367afaa Author: Lai Jiangshan <laijs@linux.alibaba.com> Date: Fri, 26 Nov 2021 18:11:22 +0800 x86/entry: Use the correct fence macro after swapgs in kernel CR3 The commit c7589070 ("x86/entry/64: Remove unneeded kernel CR3 switching") removed a CR3 write in the faulting path of load_gs_index(). But the path's FENCE_SWAPGS_USER_ENTRY has no fence operation if PTI is enabled, see spectre_v1_select_mitigation(). Rather, it depended on the serializing CR3 write of SWITCH_TO_KERNEL_CR3 and since it got removed, add a FENCE_SWAPGS_KERNEL_ENTRY call to make sure speculation is blocked. [ bp: Massage commit message and comment. ] Fixes: c7589070 ("x86/entry/64: Remove unneeded kernel CR3 switching") Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20211126101209.8613-3-jiangshanlai@gmail.com Signed-off-by:
-
Waiman Long authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2090231 commit c07e4555 Author: Lai Jiangshan <laijs@linux.alibaba.com> Date: Fri, 26 Nov 2021 18:11:21 +0800 x86/entry: Add a fence for kernel entry SWAPGS in paranoid_entry() Commit 18ec54fd ("x86/speculation: Prepare entry code for Spectre v1 swapgs mitigations") added FENCE_SWAPGS_{KERNEL|USER}_ENTRY for conditional SWAPGS. In paranoid_entry(), it uses only FENCE_SWAPGS_KERNEL_ENTRY for both branches. This is because the fence is required for both cases since the CR3 write is conditional even when PTI is enabled. But 96b23714 ("x86/entry/64: Switch CR3 before SWAPGS in paranoid entry") changed the order of SWAPGS and the CR3 write. And it missed the needed FENCE_SWAPGS_KERNEL_ENTRY for the user gsbase case. Add it back by changing the branches so that FENCE_SWAPGS_KERNEL_ENTRY can cover both branches. [ bp: Massage, fix typos, remove obsolete comment while at it. ] Fixes: 96b23714 ("x86/entry/64: Switch CR3 before SWAPGS in paranoid entry") Signed-off-by:
-
Waiman Long authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2090231 commit 988f0168 Author: Peter Zijlstra <peterz@infradead.org> Date: Thu, 2 Dec 2021 21:45:34 +0100 objtool: Fix pv_ops noinstr validation Boris reported that in one of his randconfig builds, objtool got infinitely stuck. Turns out there's trivial list corruption in the pv_ops tracking when a function is both in a static table and in a code assignment. Avoid re-adding function to the pv_ops[] lists when they're already on it. Fixes: db2b0c5d ("objtool: Support pv_opsindirect calls for noinstr") Reported-by:
Borislav Petkov <bp@alien8.de> Signed-off-by:
-
Waiman Long authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2090231 commit 2105a927 Author: Peter Zijlstra <peterz@infradead.org> Date: Sat, 30 Oct 2021 09:47:58 +0200 static_call,x86: Robustify trampoline patching Add a few signature bytes after the static call trampoline and verify those bytes match before patching the trampoline. This avoids patching random other JMPs (such as CFI jump-table entries) instead. These bytes decode as: d: 53 push %rbx e: 43 54 rex.XB push %r12 And happen to spell "SCT". Signed-off-by:
-
Waiman Long authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2090231 Conflicts: Merge conflict in the first hunk of arch/x86/xen/irq.c due to missing upstream commit 20125c87 ("x86/xen: Make save_fl() noinstr"), commit d7bfc7d5 ("x86/xen: Make irq_enable() noinstr") and commit 09c41307 ("x86/xen: Make irq_disable() noinstr"). commit e453f872 Author: Juergen Gross <jgross@suse.com> Date: Thu, 28 Oct 2021 09:27:48 +0200 x86/xen: switch initial pvops IRQ functions to dummy ones The initial pvops functions handling irq flags will only ever be called before interrupts are being enabled. So switch them to be dummy functions: - xen_save_fl() can always return 0 - xen_irq_disable() is a nop - xen_irq_enable() can BUG() Add some generic paravirt functions for that purpose. Signed-off-by:
Juergen Gross <jgross@suse.com> Acked-by:
-
Waiman Long authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2090231 Conflicts: X86_FEATURE_RETPOLINE_AMD is replaced by X86_FEATURE_RETPOLINE_LFENCE due to the presence of a later upstream commit d45476d9 ("x86/speculation: Rename RETPOLINE_AMD to RETPOLINE_LFENCE"). commit 87c87ecd Author: Peter Zijlstra <peterz@infradead.org> Date: Tue, 26 Oct 2021 14:01:48 +0200 bpf,x86: Respect X86_FEATURE_RETPOLINE* Current BPF codegen doesn't respect X86_FEATURE_RETPOLINE* flags and unconditionally emits a thunk call, this is sub-optimal and doesn't match the regular, compiler generated, code. Update the i386 JIT to emit code equal to what the compiler emits for the regular kernel text (IOW. a plain THUNK call). Update the x86_64 JIT to emit code similar to the result of compiler and kernel rewrites as according to X86_FEATURE_RETPOLINE* flags. Inlining RETPOLINE_AMD (lfence; jmp *%reg) and !RETPOLINE (jmp *%reg), while doing a THUNK call for RETPOLINE. This removes the hard-coded retpoline thunks and shrinks the generated code. Leaving a single retpoline thunk definition in the kernel. Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Acked-by:
Josh Poimboeuf <jpoimboe@redhat.com> Tested-by:
-
Waiman Long authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2090231 commit d4b5a5c9 Author: Peter Zijlstra <peterz@infradead.org> Date: Tue, 26 Oct 2021 14:01:45 +0200 x86/alternative: Add debug prints to apply_retpolines() Make sure we can see the text changes when booting with 'debug-alternative'. Example output: [ ] SMP alternatives: retpoline at: __traceiter_initcall_level+0x1f/0x30 (ffffffff8100066f) len: 5 to: __x86_indirect_thunk_rax+0x0/0x20 [ ] SMP alternatives: ffffffff82603e58: [2:5) optimized NOPs: ff d0 0f 1f 00 [ ] SMP alternatives: ffffffff8100066f: orig: e8 cc 30 00 01 [ ] SMP alternatives: ffffffff8100066f: repl: ff d0 0f 1f 00 Signed-off-by:
-
Waiman Long authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2090231 Conflicts: X86_FEATURE_RETPOLINE_AMD is replaced by X86_FEATURE_RETPOLINE_LFENCE due to the presence of a later upstream commit d45476d9 ("x86/speculation: Rename RETPOLINE_AMD to RETPOLINE_LFENCE"). commit bbe2df3f Author: Peter Zijlstra <peterz@infradead.org> Date: Tue, 26 Oct 2021 14:01:44 +0200 x86/alternative: Try inline spectre_v2=retpoline,amd Try and replace retpoline thunk calls with: LFENCE CALL *%\reg for spectre_v2=retpoline,amd. Specifically, the sequence above is 5 bytes for the low 8 registers, but 6 bytes for the high 8 registers. This means that unless the compilers prefix stuff the call with higher registers this replacement will fail. Luckily GCC strongly favours RAX for the indirect calls and most (95%+ for defconfig-x86_64) will be converted. OTOH clang strongly favours R11 and almost nothing gets converted. Note: it will also generate a correct replacement for the Jcc.d32 case, except unless the compilers start to prefix stuff that, it'll never fit. Specifically: Jncc.d8 1f LFENCE JMP *%\reg 1: is 7-8 bytes long, where the original instruction in unpadded form is only 6 bytes. Signed-off-by:
-
Waiman Long authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2090231 commit 2f0cbb2a Author: Peter Zijlstra <peterz@infradead.org> Date: Tue, 26 Oct 2021 14:01:43 +0200 x86/alternative: Handle Jcc __x86_indirect_thunk_\reg Handle the rare cases where the compiler (clang) does an indirect conditional tail-call using: Jcc __x86_indirect_thunk_\reg For the !RETPOLINE case this can be rewritten to fit the original (6 byte) instruction like: Jncc.d8 1f JMP *%\reg NOP 1: Signed-off-by:
-
Waiman Long authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2090231 commit 75085009 Author: Peter Zijlstra <peterz@infradead.org> Date: Tue, 26 Oct 2021 14:01:42 +0200 x86/alternative: Implement .retpoline_sites support Rewrite retpoline thunk call sites to be indirect calls for spectre_v2=off. This ensures spectre_v2=off is as near to a RETPOLINE=n build as possible. This is the replacement for objtool writing alternative entries to ensure the same and achieves feature-parity with the previous approach. One noteworthy feature is that it relies on the thunks to be in machine order to compute the register index. Specifically, this does not yet address the Jcc __x86_indirect_thunk_* calls generated by clang, a future patch will add this. Signed-off-by:
-
Waiman Long authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2090231 Conflicts: Merge conflict in arch/x86/lib/retpoline.S due to the presence of a later upstream commit d45476d9 ("x86/speculation: Rename RETPOLINE_AMD to RETPOLINE_LFENCE"). commit 1a6f7442 Author: Peter Zijlstra <peterz@infradead.org> Date: Tue, 26 Oct 2021 14:01:41 +0200 x86/retpoline: Create a retpoline thunk array Stick all the retpolines in a single symbol and have the individual thunks as inner labels, this should guarantee thunk order and layout. Previously there were 16 (or rather 15 without rsp) separate symbols and a toolchain might reasonably expect it could displace them however it liked, with disregard for their relative position. However, now they're part of a larger symbol. Any change to their relative position would disrupt this larger _array symbol and thus not be sound. This is the same reasoning used for data symbols. On their own there is no guarantee about their relative position wrt to one aonther, but we're still able to do arrays because an array as a whole is a single larger symbol. Signed-off-by:
-
Waiman Long authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2090231 commit 6fda8a38 Author: Peter Zijlstra <peterz@infradead.org> Date: Tue, 26 Oct 2021 14:01:40 +0200 x86/retpoline: Move the retpoline thunk declarations to nospec-branch.h Because it makes no sense to split the retpoline gunk over multiple headers. Signed-off-by:
-
Waiman Long authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2090231 commit b6d3d994 Author: Peter Zijlstra <peterz@infradead.org> Date: Tue, 26 Oct 2021 14:01:39 +0200 x86/asm: Fixup odd GEN-for-each-reg.h usage Currently GEN-for-each-reg.h usage leaves GEN defined, relying on any subsequent usage to start with #undef, which is rude. Signed-off-by:
-
Waiman Long authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2090231 commit a92ede2d Author: Peter Zijlstra <peterz@infradead.org> Date: Tue, 26 Oct 2021 14:01:38 +0200 x86/asm: Fix register order Ensure the register order is correct; this allows for easy translation between register number and trampoline and vice-versa. Signed-off-by:
-
Waiman Long authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2090231 commit 4fe79e71 Author: Peter Zijlstra <peterz@infradead.org> Date: Tue, 26 Oct 2021 14:01:37 +0200 x86/retpoline: Remove unused replacement symbols Now that objtool no longer creates alternatives, these replacement symbols are no longer needed, remove them. Signed-off-by:
-
Waiman Long authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2090231 commit 134ab5bd Author: Peter Zijlstra <peterz@infradead.org> Date: Tue, 26 Oct 2021 14:01:36 +0200 objtool,x86: Replace alternatives with .retpoline_sites Instead of writing complete alternatives, simply provide a list of all the retpoline thunk calls. Then the kernel is free to do with them as it pleases. Simpler code all-round. Signed-off-by:
-
Waiman Long authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2090231 commit c509331b Author: Peter Zijlstra <peterz@infradead.org> Date: Tue, 26 Oct 2021 14:01:35 +0200 objtool: Shrink struct instruction Any one instruction can only ever call a single function, therefore insn->mcount_loc_node is superfluous and can use insn->call_node. This shrinks struct instruction, which is by far the most numerous structure objtool creates. Signed-off-by:
-
Waiman Long authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2090231 commit dd003ede Author: Peter Zijlstra <peterz@infradead.org> Date: Tue, 26 Oct 2021 14:01:34 +0200 objtool: Explicitly avoid self modifying code in .altinstr_replacement Assume ALTERNATIVE()s know what they're doing and do not change, or cause to change, instructions in .altinstr_replacement sections. Signed-off-by:
-
Waiman Long authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2090231 commit 1739c66e Author: Peter Zijlstra <peterz@infradead.org> Date: Tue, 26 Oct 2021 14:01:33 +0200 objtool: Classify symbols In order to avoid calling str*cmp() on symbol names, over and over, do them all once upfront and store the result. Signed-off-by:
-
Waiman Long authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2090231 commit 4d8b3596 Author: Josh Poimboeuf <jpoimboe@kernel.org> Date: Mon, 4 Oct 2021 10:07:50 -0700 objtool: Remove reloc symbol type checks in get_alt_entry() Converting a special section's relocation reference to a symbol is straightforward. No need for objtool to complain that it doesn't know how to handle it. Just handle it. This fixes the following warning: arch/x86/kvm/emulate.o: warning: objtool: __ex_table+0x4: don't know how to handle reloc symbol type: kvm_fastop_exception Fixes: 24ff6525 ("objtool: Teach get_alt_entry() about more relocation types") Reported-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Waiman Long authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2090231 commit 7fab1c12 Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Sun, 3 Oct 2021 13:45:48 -0700 objtool: print out the symbol type when complaining about it The objtool warning that the kvm instruction emulation code triggered wasn't very useful: arch/x86/kvm/emulate.o: warning: objtool: __ex_table+0x4: don't know how to handle reloc symbol type: kvm_fastop_exception in that it helpfully tells you which symbol name it had trouble figuring out the relocation for, but it doesn't actually say what the unknown symbol type was that triggered it all. In this case it was because of missing type information (type 0, aka STT_NOTYPE), but on the whole it really should just have printed that out as part of the message. Because if this warning triggers, that's very much the first thing you want to know - why did reloc2sec_off() return failure for that symbol? So rather than just saying you can't handle some type of symbol without saying what the type _was_, just print out the type number too. Fixes: 24ff6525 ("objtool: Teach get_alt_entry() about more relocation types") Link: https://lore.kernel.org/lkml/CAHk-=wiZwq-0LknKhXN4M+T8jbxn_2i9mcKpO+OaBSSq_Eh7tg@mail.gmail.com/ Signed-off-by:
-
Waiman Long authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2090231 commit 24ff6525 Author: Peter Zijlstra <peterz@infradead.org> Date: Thu, 30 Sep 2021 12:43:10 +0200 objtool: Teach get_alt_entry() about more relocation types Occasionally objtool encounters symbol (as opposed to section) relocations in .altinstructions. Typically they are the alternatives written by elf_add_alternative() as encountered on a noinstr validation run on vmlinux after having already ran objtool on the individual .o files. Basically this is the counterpart of commit 44f6a7c0 ("objtool: Fix seg fault with Clang non-section symbols"), because when these new assemblers (binutils now also does this) strip the section symbols, elf_add_reloc_to_insn() is forced to emit symbol based relocations. As such, teach get_alt_entry() about different relocation types. Fixes: 9bc0bb50 ("objtool/x86: Rewrite retpoline thunk calls") Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Reported-by:
Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/YVWUvknIEVNkPvnP@hirez.programming.kicks-ass.net Signed-off-by:
-
Waiman Long authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2090231 commit 90a35349 Author: Masahiro Yamada <masahiroy@kernel.org> Date: Tue, 31 Aug 2021 16:39:57 +0900 kbuild: reuse $(cmd_objtool) for cmd_cc_lto_link_modules For CONFIG_LTO_CLANG=y, the objtool processing is not possible at the compilation, hence postponed by the link time. Reuse $(cmd_objtool) for CONFIG_LTO_CLANG=y by defining objtool-enabled properly. For CONFIG_LTO_CLANG=y: objtool-enabled is off for %.o compilation objtool-enabled is on for %.lto link For CONFIG_LTO_CLANG=n: objtool-enabled is on for %.o compilation (but, it depends on OBJECT_FILE_NON_STANDARD) Set part-of-module := y for %.lto.o to avoid repeating --module. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Reviewed-by:
Kees Cook <keescook@chromium.org> Acked-by:
-
Waiman Long authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2090231 commit ef62588c Author: Masahiro Yamada <masahiroy@kernel.org> Date: Tue, 31 Aug 2021 16:39:56 +0900 kbuild: detect objtool update without using .SECONDEXPANSION Redo commit 8852c552 ("kbuild: Fix objtool dependency for 'OBJECT_FILES_NON_STANDARD_<obj> := n'") to add the objtool dependency in a cleaner way. Using .SECONDEXPANSION ends up with unreadable code due to escaped dollars. Also, it is not efficient because the second half of Makefile.build is parsed twice every time. Append the objtool dependency to the *.cmd files at the build time. This is what fixdep and gen_ksymdeps.sh already do. So, following the same pattern seems a natural solution. This allows us to drop $$(objtool_dep) entirely. Signed-off-by:
Nick Desaulniers <ndesaulniers@google.com> Acked-by:
-
Waiman Long authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2090231 commit 918a6b7f Author: Masahiro Yamada <masahiroy@kernel.org> Date: Tue, 31 Aug 2021 16:39:55 +0900 kbuild: factor out OBJECT_FILES_NON_STANDARD check into a macro The OBJECT_FILES_NON_STANDARD check is quite long. Factor it out into a new macro, objtool-enabled, to not repeat it. Signed-off-by:
-
Waiman Long authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2090231 commit 92594d56 Author: Masahiro Yamada <masahiroy@kernel.org> Date: Tue, 31 Aug 2021 16:39:54 +0900 kbuild: store the objtool command in *.cmd files objtool_dep includes include/config/{ORC_UNWINDER,STACK_VALIDATION} so that all the objects are rebuilt when CONFIG_ORC_UNWINDER or CONFIG_STACK_VALIDATION is toggled. BTW, the correct option name is not CONFIG_ORC_UNWINDER, but CONFIG_UNWINDER_ORC. Commit 11af8474 ("x86/unwind: Rename unwinder config options to 'CONFIG_UNWINDER_*'") missed to adjust this part. So, this dependency has been broken for a long time. As you can see in 'objtool_args', there are more CONFIG options that affect the objtool command line. Adding more and more include/config/* is ugly and unmaintainable. Another issue is that non-standard objects are needlessly rebuilt. Objects specified as OBJECT_FILES_NON_STANDARD is not processed by objtool, but they are rebuilt anyway when CONFIG_STACK_VALIDATION is toggled. This is not a big deal, but better to fix. A cleaner and more precise fix is to include the objtool command in *.cmd files so any command change is naturally detected by if_change. Signed-off-by:
-
Waiman Long authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2090231 commit 5c4859e7 Author: Masahiro Yamada <masahiroy@kernel.org> Date: Tue, 31 Aug 2021 16:39:53 +0900 kbuild: rename __objtool_obj and reuse it for cmd_cc_lto_link_modules Rename __objtool_obj to objtool, and move it out of the 'ifndef CONFIG_LTO_CLANG' conditional, so it can be used for cmd_cc_lto_link_modules as well. Signed-off-by:
-
Waiman Long authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2090231 commit 8f0c32c7 Author: Masahiro Yamada <masahiroy@kernel.org> Date: Tue, 31 Aug 2021 16:39:52 +0900 kbuild: move objtool_args back to scripts/Makefile.build Commit b1a1a1a0 ("kbuild: lto: postpone objtool") moved objtool_args to Makefile.lib, so the arguments can be used in Makefile.modfinal as well as Makefile.build. With commit 850ded46 ("kbuild: Fix TRIM_UNUSED_KSYMS with LTO_CLANG"), module LTO linking came back to scripts/Makefile.build again. So, there is no more reason to keep objtool_args in a separate file. Get it back to the original place, close to the objtool command. Remove the stale comment too. Signed-off-by:
-
Waiman Long authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2090231 commit 69065847 Author: Tony Luck <tony.luck@intel.com> Date: Tue, 17 Aug 2021 17:29:42 -0700 x86/mce: Drop copyin special case for #MC Fixes to the iterator code to handle faults that are not on page boundaries mean that the special case for machine check during copy from user is no longer needed. For a full list of those fixes, see the output of: git log --oneline v5.14 ^v5.13 -- lib/iov_iter.c Signed-off-by:
Tony Luck <tony.luck@intel.com> Signed-off-by:
-
Waiman Long authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2090231 Conflicts: Merge conflict in the decode_instructions() hunk of tools/objtool/check.c due to upstream merge conflict with commit fe255fe6 ("objtool: Remove redundant 'len' field from struct section"). Resolve it as in upstream merge commit b08cadbd ("Merge branch 'objtool/urgent'"). commit db2b0c5d Author: Peter Zijlstra <peterz@infradead.org> Date: Thu, 24 Jun 2021 11:41:23 +0200 objtool: Support pv_opsindirect calls for noinstr Normally objtool will now follow indirect calls; there is no need. However, this becomes a problem with noinstr validation; if there's an indirect call from noinstr code, we very much need to know it is to another noinstr function. Luckily there aren't many indirect calls in entry code with the obvious exception of paravirt. As such, noinstr validation didn't work with paravirt kernels. In order to track pv_ops[] call targets, objtool reads the static pv_ops[] tables as well as direct assignments to the pv_ops[] array, provided the compiler makes them a single instruction like: bf87: 48 c7 05 00 00 00 00 00 00 00 00 movq $0x0,0x0(%rip) bf92 <xen_init_spinlocks+0x5f> bf8a: R_X86_64_PC32 pv_ops+0x268 There are, as of yet, no warnings for when this goes wrong :/ Using the functions found with the above means, all pv_ops[] calls are now subject to noinstr validation. Signed-off-by:
-
Waiman Long authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2090231 commit 1462eb38 Author: Peter Zijlstra <peterz@infradead.org> Date: Thu, 24 Jun 2021 11:41:22 +0200 x86/xen: Rework the xen_{cpu,irq,mmu}_opsarrays In order to allow objtool to make sense of all the various paravirt functions, it needs to either parse whole pv_ops[] tables, or observe individual assignments in the form: bf87: 48 c7 05 00 00 00 00 00 00 00 00 movq $0x0,0x0(%rip) bf92 <xen_init_spinlocks+0x5f> bf8a: R_X86_64_PC32 pv_ops+0x268 As is, xen_cpu_ops[] is at offset +0 in pv_ops[] and could thus be parsed as a 'normal' pv_ops[] table, however xen_irq_ops[] and xen_mmu_ops[] are not. Worse, both the latter two are compiled into the individual assignment for by current GCC, but that's not something one can rely on. Therefore, convert all three into full pv_ops[] tables. This has the benefit of not needing to teach objtool about the offsets and resulting in more conservative code-gen. Signed-off-by:
-
Waiman Long authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2090231 commit f56dae88 Author: Peter Zijlstra <peterz@infradead.org> Date: Thu, 24 Jun 2021 11:41:02 +0200 objtool: Handle __sanitize_cov*() tail calls Turns out the compilers also generate tail calls to __sanitize_cov*(), make sure to also patch those out in noinstr code. Fixes: 0f1441b4 ("objtool: Fix noinstr vs KCOV") Signed-off-by:
Marco Elver <elver@google.com> Link: https://lore.kernel.org/r/20210624095147.818783799@infradead.org Signed-off-by:
-
Waiman Long authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2090231 commit 8b946cc3 Author: Peter Zijlstra <peterz@infradead.org> Date: Thu, 24 Jun 2021 11:41:01 +0200 objtool: Introduce CFI hash Andi reported that objtool on vmlinux.o consumes more memory than his system has, leading to horrific performance. This is in part because we keep a struct instruction for every instruction in the file in-memory. Shrink struct instruction by removing the CFI state (which includes full register state) from it and demand allocating it. Given most instructions don't actually change CFI state, there's lots of repetition there, so add a hash table to find previous CFI instances. Reduces memory consumption (and runtime) for processing an x86_64-allyesconfig: pre: 4:40.84 real, 143.99 user, 44.18 sys, 30624988 mem post: 2:14.61 real, 108.58 user, 25.04 sys, 16396184 mem Suggested-by:
Andi Kleen <andi@firstfloor.org> Signed-off-by:
-
Waiman Long authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2090231 commit 44815c90 Author: Masahiro Yamada <masahiroy@kernel.org> Date: Sat, 28 Aug 2021 18:51:01 +0900 kbuild: clean up objtool_args slightly The code: $(if $(or $(CONFIG_GCOV_KERNEL),$(CONFIG_LTO_CLANG)), ...) ... can be simpled to: $(if $(CONFIG_GCOV_KERNEL)$(CONFIG_LTO_CLANG), ...) Also, remove meaningless commas at the end of $(if ...). Signed-off-by:
-
Waiman Long authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2090231 commit a8390ba9 Author: Masahiro Yamada <masahiroy@kernel.org> Date: Thu, 19 Aug 2021 09:57:36 +0900 kbuild: remove stale *.symversions cmd_update_lto_symversions merges all the existing *.symversions, but some of them might be stale. If the last EXPORT_SYMBOL is removed from a C file, the *.symversions file is not deleted or updated. It contains stale CRCs, but still they will be used for linking the vmlinux or modules. It is not a big deal when the EXPORT_SYMBOL is really removed. However, when the EXPORT_SYMBOL is moved to another file, the same __crc_<symbol> will appear twice in the merged *.symversions, possibly with different CRCs if the function argument is changed at the same time. It would confuse module versioning. If no EXPORT_SYMBOL is found, let's remove *.symversions explicitly. Signed-off-by:
-
Waiman Long authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2090231 commit f01ac2a1 Author: Masahiro Yamada <masahiroy@kernel.org> Date: Thu, 19 Aug 2021 09:57:35 +0900 kbuild: remove unused quiet_cmd_update_lto_symversions This is not used anywhere because the short log is displayed when it is used through a $(call cmd,...) invocation. Signed-off-by:
-
Waiman Long authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2090231 commit 850ded46 Author: Sami Tolvanen <samitolvanen@google.com> Date: Mon, 16 Aug 2021 11:05:19 -0700 kbuild: Fix TRIM_UNUSED_KSYMS with LTO_CLANG With CONFIG_LTO_CLANG, we currently link modules into native code just before modpost, which means with TRIM_UNUSED_KSYMS enabled, we still look at the LLVM bitcode in the .o files when generating the list of used symbols. As the bitcode doesn't yet have calls to compiler intrinsics and llvm-nm doesn't see function references that only exist in function-level inline assembly, we currently need a whitelist for TRIM_UNUSED_KSYMS to work with LTO. This change moves module LTO linking to happen earlier, and thus avoids the issue with LLVM bitcode and TRIM_UNUSED_KSYMS entirely, allowing us to also drop the whitelist from gen_autoksyms.sh. Link: https://github.com/ClangBuiltLinux/linux/issues/1369 Signed-off-by:
Sami Tolvanen <samitolvanen@google.com> Reviewed-by:
Alexander Lobakin <alobakin@pm.me> Tested-by:
-
Waiman Long authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2090231 Conflicts: A fuzz in Makefile due to the presence of a later upstream commit 86cffecd ("Compiler Attributes: add __alloc_size() for better bounds checking"). commit 7d73c3e9 Author: Nick Desaulniers <ndesaulniers@google.com> Date: Mon, 16 Aug 2021 13:25:01 -0700 Makefile: remove stale cc-option checks cc-option, cc-option-yn, and cc-disable-warning all invoke the compiler during build time, and can slow down the build when these checks become stale for our supported compilers, whose minimally supported versions increases over time. See Documentation/process/changes.rst for the current supported minimal versions (GCC 4.9+, clang 10.0.1+). Compiler version support for these flags may be verified on godbolt.org. The following flags are GCC only and supported since at least GCC 4.9. Remove cc-option and cc-disable-warning tests. * -fno-tree-loop-im * -Wno-maybe-uninitialized * -fno-reorder-blocks * -fno-ipa-cp-clone * -fno-partial-inlining * -femit-struct-debug-baseonly * -fno-inline-functions-called-once * -fconserve-stack The following flags are supported by all supported versions of GCC and Clang. Remove their cc-option, cc-option-yn, and cc-disable-warning tests. * -fno-delete-null-pointer-checks * -fno-var-tracking * -Wno-array-bounds The following configs are made dependent on GCC, since they use GCC specific flags. * READABLE_ASM * DEBUG_SECTION_MISMATCH -mfentry was not supported by s390-linux-gnu-gcc until gcc-9+, add a comment. --param=allow-store-data-races=0 was renamed to -fno-allow-store-data-races in the GCC 10 release; add a comment. -Wmaybe-uninitialized (GCC specific) was being added for CONFIG_GCOV, then again unconditionally; add it only once. Also, base RETPOLINE_CFLAGS and RETPOLINE_VDSO_CFLAGS on CONFIC_CC_IS_* then remove cc-option tests for Clang. Link: https://github.com/ClangBuiltLinux/linux/issues/1436 Acked-by:
Miguel Ojeda <ojeda@kernel.org> Reviewed-by:
-
Waiman Long authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2090231 commit 989ceac7 Author: Nick Desaulniers <ndesaulniers@google.com> Date: Thu, 12 Aug 2021 11:38:48 -0700 x86/build: Remove stale cc-option checks cc-option, __cc-option, cc-option-yn, and cc-disable-warning all invoke the compiler during build time, and can slow down the build when these checks become stale for our supported compilers, whose minimally supported versions increases over time. See Documentation/process/changes.rst for the current supported minimal versions (GCC 4.9+, clang 10.0.1+). Compiler version support for these flags may be verified on godbolt.org. The following flags are supported by all supported versions of GCC and Clang. Remove their cc-option, __cc-option, and cc-option-yn tests. -Wno-address-of-packed-member -mno-avx -m32 -mno-80387 -march=k8 -march=nocona -march=core2 -march=atom -mtune=generic -mfentry [ mingo: Fixed regression on GCC, via partial revert of the stack-boundary changes. ] Signed-off-by:
Ingo Molnar <mingo@kernel.org> Link: https://github.com/ClangBuiltLinux/linux/issues/1436 Link: https://lkml.kernel.org/r/20210812183848.1519994-1-ndesaulniers@google.com Signed-off-by:
-
