- 26 Oct, 2022 2 commits
-
-
Kees Cook authored
commit 607e57c6 upstream. Now that Clang's -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang option is no longer required, remove it from the command line. Clang 16 and later will warn when it is used, which will cause Kconfig to think it can't use -ftrivial-auto-var-init=zero at all. Check for whether it is required and only use it when so. Cc: Nathan Chancellor <nathan@kernel.org> Cc: Masahiro Yamada <masahiroy@kernel.org> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: linux-kbuild@vger.kernel.org Cc: llvm@lists.linux.dev Cc: stable@vger.kernel.org Fixes: f02003c8 ("hardening: Avoid harmless Clang option under CONFIG_INIT_STACK_ALL_ZERO") Signed-off-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
Nathan Chancellor <nathan@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Kees Cook authored
commit f02003c8 upstream. Currently under Clang, CC_HAS_AUTO_VAR_INIT_ZERO requires an extra -enable flag compared to CC_HAS_AUTO_VAR_INIT_PATTERN. GCC 12[1] will not, and will happily ignore the Clang-specific flag. However, its presence on the command-line is both cumbersome and confusing. Due to GCC's tolerant behavior, though, we can continue to use a single Kconfig cc-option test for the feature on both compilers, but then drop the Clang-specific option in the Makefile. In other words, this patch does not change anything other than making the compiler command line shorter once GCC supports -ftrivial-auto-var-init=zero. [1] https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=a25e0b5e6ac8a77a71c229e0a7b744603365b0e9 Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Masahiro Yamada <masahiroy@kernel.org> Cc: llvm@lists.linux.dev Fixes: dcb7c0b9 ("hardening: Clarify Kconfig text for auto-var-init") Suggested-by:
Will Deacon <will@kernel.org> Link: https://lore.kernel.org/lkml/20210914102837.6172-1-will@kernel.org/ Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Reviewed-by:
-
- 17 Oct, 2022 1 commit
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20221016064454.382206984@linuxfoundation.org Tested-by:
Rudi Heitbaum <rudi@heitbaum.com> Tested-by:
Pavel Machek (CIP) <pavel@denx.de> Tested-by:
Guenter Roeck <linux@roeck-us.net> Tested-by:
Linux Kernel Functional Testing <lkft@linaro.org> Tested-by:
Sudip Mukherjee <sudip.mukherjee@codethink.co.uk> Tested-by:
Jon Hunter <jonathanh@nvidia.com> Signed-off-by:
-
- 15 Oct, 2022 1 commit
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20221013175147.337501757@linuxfoundation.org Tested-by:
Florian Fainelli <f.fainelli@gmail.com> Tested-by:
Shuah Khan <skhan@linuxfoundation.org> Tested-by:
Slade Watkins <srw@sladewatkins.net> Tested-by:
-
- 05 Oct, 2022 1 commit
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20221003070718.687440096@linuxfoundation.org Tested-by:
Allen Pais <apais@linux.microsoft.com> Tested-by:
-
- 28 Sep, 2022 1 commit
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20220926100754.639112000@linuxfoundation.org Tested-by:
-
- 23 Sep, 2022 1 commit
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20220921153645.663680057@linuxfoundation.org Tested-by:
Salvatore Bonaccorso <carnil@debian.org> Tested-by:
-
- 20 Sep, 2022 1 commit
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20220916100445.354452396@linuxfoundation.org Tested-by:
Hulk Robot <hulkrobot@huawei.com> Signed-off-by:
-
- 15 Sep, 2022 1 commit
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20220913140350.291927556@linuxfoundation.org Tested-by:
-
- 08 Sep, 2022 1 commit
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20220906132816.936069583@linuxfoundation.org Tested-by:
-
- 05 Sep, 2022 1 commit
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20220902121359.177846782@linuxfoundation.org Tested-by:
-
- 31 Aug, 2022 1 commit
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20220829105756.500128871@linuxfoundation.org Tested-by:
Slade Watkins <slade@sladewatkins.com> Tested-by:
-
- 29 Aug, 2022 1 commit
-
-
Greg Kroah-Hartman authored
Signed-off-by:
-
- 25 Aug, 2022 2 commits
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20220823080059.091088642@linuxfoundation.org Tested-by:
Ron Economos <re@w6rz.net> Tested-by:
-
Masahiro Yamada authored
commit 11314751 upstream. Commit b2c88554 ("kbuild: update modules.order only when contained modules are updated") accidentally changed the modules order. Prior to that commit, the modules order was determined based on vmlinux-dirs, which lists core-y/m, drivers-y/m, libs-y/m, in this order. Now, subdir-modorder lists them in a different order: core-y/m, libs-y/m, drivers-y/m. Presumably, there was no practical issue because the modules in drivers and libs are orthogonal, but there is no reason to have this distortion. Get back to the original order. Fixes: b2c88554 ("kbuild: update modules.order only when contained modules are updated") Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Signed-off-by:
-
- 21 Aug, 2022 2 commits
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20220819153829.135562864@linuxfoundation.org Tested-by:
-
Nick Desaulniers authored
commit 0d362be5 upstream. Users of GNU ld (BFD) from binutils 2.39+ will observe multiple instances of a new warning when linking kernels in the form: ld: warning: vmlinux: missing .note.GNU-stack section implies executable stack ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker ld: warning: vmlinux has a LOAD segment with RWX permissions Generally, we would like to avoid the stack being executable. Because there could be a need for the stack to be executable, assembler sources have to opt-in to this security feature via explicit creation of the .note.GNU-stack feature (which compilers create by default) or command line flag --noexecstack. Or we can simply tell the linker the production of such sections is irrelevant and to link the stack as --noexecstack. LLVM's LLD linker defaults to -z noexecstack, so this flag isn't strictly necessary when linking with LLD, only BFD, but it doesn't hurt to be explicit here for all linkers IMO. --no-warn-rwx-segments is currently BFD specific and only available in the current latest release, so it's wrapped in an ld-option check. While the kernel makes extensive usage of ELF sections, it doesn't use permissions from ELF segments. Link: https://lore.kernel.org/linux-block/3af4127a-f453-4cf7-f133-a181cce06f73@kernel.dk/ Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=ba951afb99912da01a6e8434126b8fac7aa75107 Link: https://github.com/llvm/llvm-project/issues/57009 Reported-and-tested-by:
Jens Axboe <axboe@kernel.dk> Suggested-by:
Fangrui Song <maskray@google.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
- 11 Aug, 2022 1 commit
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20220809175512.853274191@linuxfoundation.org Tested-by:
-
- 03 Aug, 2022 1 commit
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20220801114133.641770326@linuxfoundation.org Tested-by:
-
- 29 Jul, 2022 1 commit
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20220727161012.056867467@linuxfoundation.org Tested-by:
-
- 25 Jul, 2022 5 commits
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20220723095224.302504400@linuxfoundation.org Tested-by:
-
Peter Zijlstra authored
commit 68cf4f2a upstream. In order to further enable commit: bbe2df3f ("x86/alternative: Try inline spectre_v2=retpoline,amd") add the new GCC flag -mindirect-branch-cs-prefix: https://gcc.gnu.org/g:2196a681d7810ad8b227bf983f38ba716620545e https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102952 https://bugs.llvm.org/show_bug.cgi?id=52323 to RETPOLINE=y builds. This should allow fully inlining retpoline,amd for GCC builds. Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by:
Borislav Petkov <bp@suse.de> Reviewed-by:
-
Peter Zijlstra authored
commit f43b9876 upstream. Do fine-grained Kconfig for all the various retbleed parts. NOTE: if your compiler doesn't support return thunks this will silently 'upgrade' your mitigation to IBPB, you might not like this. Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com> [bwh: Backported to 5.10: - In scripts/Makefile.build, add the objtool option with an ifdef block, same as for other options - Adjust filename, context] Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Peter Zijlstra authored
commit 0b53c374 upstream. Utilize -mfunction-return=thunk-extern when available to have the compiler replace RET instructions with direct JMPs to the symbol __x86_return_thunk. This does not affect assembler (.S) sources, only C sources. -mfunction-return=thunk-extern has been available since gcc 7.3 and clang 15. Signed-off-by:
Josh Poimboeuf <jpoimboe@kernel.org> Tested-by:
-
Ben Hutchings authored
This was done as part of commit 7d73c3e9 "Makefile: remove stale cc-option checks" upstream, and is needed to support backporting further retpoline changes. Signed-off-by:
-
- 21 Jul, 2022 1 commit
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20220719114626.156073229@linuxfoundation.org Tested-by:
-
- 15 Jul, 2022 1 commit
-
-
Greg Kroah-Hartman authored
Signed-off-by:
-
- 12 Jul, 2022 1 commit
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20220711090541.764895984@linuxfoundation.org Tested-by:
-
- 07 Jul, 2022 1 commit
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20220705115615.323395630@linuxfoundation.org Tested-by:
-
- 02 Jul, 2022 1 commit
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20220630133230.676254336@linuxfoundation.org Tested-by:
-
- 29 Jun, 2022 2 commits
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20220627111933.455024953@linuxfoundation.org Tested-by:
-
Masahiro Yamada authored
commit 53632ba8 upstream. If CONFIG_TRIM_UNUSED_KSYMS is enabled and the kernel is built from a pristine state, the vmlinux is linked twice. Commit 3fdc7d3f ("kbuild: link vmlinux only once for CONFIG_TRIM_UNUSED_KSYMS") explains why this happens, but it did not fix the issue at all. Now I realized I had applied a wrong patch. In v1 patch [1], the autoksyms_recursive target correctly recurses to "$(MAKE) -f $(srctree)/Makefile autoksyms_recursive". In v2 patch [2], I accidentally dropped the diff line, and it recurses to "$(MAKE) -f $(srctree)/Makefile vmlinux". Restore the code I intended in v1. [1]: https://lore.kernel.org/linux-kbuild/1521045861-22418-8-git-send-email-yamada.masahiro@socionext.com/ [2]: https://lore.kernel.org/linux-kbuild/1521166725-24157-8-git-send-email-yamada.masahiro@socionext.com/ Fixes: 3fdc7d3f ("kbuild: link vmlinux only once for CONFIG_TRIM_UNUSED_KSYMS") Signed-off-by:
Sami Tolvanen <samitolvanen@google.com> Reviewed-by:
-
- 27 Jun, 2022 1 commit
-
-
Greg Kroah-Hartman authored
Signed-off-by:
-
- 25 Jun, 2022 1 commit
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20220623164322.296526800@linuxfoundation.org Tested-by:
-
- 22 Jun, 2022 1 commit
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20220620124720.882450983@linuxfoundation.org Tested-by:
Fox Chen <foxhlchen@gmail.com> Tested-by:
-
- 16 Jun, 2022 1 commit
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20220614183719.878453780@linuxfoundation.org Tested-by:
Tyler Hicks <tyhicks@linux.microsoft.com> Tested-by:
-
- 14 Jun, 2022 1 commit
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20220613094850.166931805@linuxfoundation.org Tested-by:
-
- 09 Jun, 2022 1 commit
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20220607164908.521895282@linuxfoundation.org Tested-by:
-
- 06 Jun, 2022 1 commit
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20220603173818.716010877@linuxfoundation.org Tested-by:
-
- 30 May, 2022 1 commit
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20220527084828.156494029@linuxfoundation.org Tested-by:
-
