summaryrefslogtreecommitdiff
path: root/scripts
AgeCommit message (Collapse)AuthorFilesLines
2022-08-25gcc-plugins: Undefine LATENT_ENTROPY_PLUGIN when plugin disabled for a fileAndrew Donnellan1-1/+1
commit 012e8d2034f1bda8863435cd589636e618d6a659 upstream. Commit 36d4b36b6959 ("lib/nodemask: inline next_node_in() and node_random()") refactored some code by moving node_random() from lib/nodemask.c to include/linux/nodemask.h, thus requiring nodemask.h to include random.h, which conditionally defines add_latent_entropy() depending on whether the macro LATENT_ENTROPY_PLUGIN is defined. This broke the build on powerpc, where nodemask.h is indirectly included in arch/powerpc/kernel/prom_init.c, part of the early boot machinery that is excluded from the latent entropy plugin using DISABLE_LATENT_ENTROPY_PLUGIN. It turns out that while we add a gcc flag to disable the actual plugin, we don't undefine LATENT_ENTROPY_PLUGIN. This leads to the following: CC arch/powerpc/kernel/prom_init.o In file included from ./include/linux/nodemask.h:97, from ./include/linux/mmzone.h:17, from ./include/linux/gfp.h:7, from ./include/linux/xarray.h:15, from ./include/linux/radix-tree.h:21, from ./include/linux/idr.h:15, from ./include/linux/kernfs.h:12, from ./include/linux/sysfs.h:16, from ./include/linux/kobject.h:20, from ./include/linux/pci.h:35, from arch/powerpc/kernel/prom_init.c:24: ./include/linux/random.h: In function 'add_latent_entropy': ./include/linux/random.h:25:46: error: 'latent_entropy' undeclared (first use in this function); did you mean 'add_latent_entropy'? 25 | add_device_randomness((const void *)&latent_entropy, sizeof(latent_entropy)); | ^~~~~~~~~~~~~~ | add_latent_entropy ./include/linux/random.h:25:46: note: each undeclared identifier is reported only once for each function it appears in make[2]: *** [scripts/Makefile.build:249: arch/powerpc/kernel/prom_init.o] Fehler 1 make[1]: *** [scripts/Makefile.build:465: arch/powerpc/kernel] Fehler 2 make: *** [Makefile:1855: arch/powerpc] Error 2 Change the DISABLE_LATENT_ENTROPY_PLUGIN flags to undefine LATENT_ENTROPY_PLUGIN for files where the plugin is disabled. Cc: Yury Norov <yury.norov@gmail.com> Fixes: 38addce8b600 ("gcc-plugins: Add latent_entropy plugin") Link: https://bugzilla.kernel.org/show_bug.cgi?id=216367 Link: https://lore.kernel.org/linuxppc-dev/alpine.DEB.2.22.394.2208152006320.289321@ramsan.of.borg/ Reported-by: Erhard Furtner <erhard_f@mailbox.org> Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com> Reviewed-by: Yury Norov <yury.norov@gmail.com> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20220816051720.44108-1-ajd@linux.ibm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-08-25kbuild: dummy-tools: avoid tmpdir leak in dummy gccOndrej Mosnacek1-6/+2
commit aac289653fa5adf9e9985e4912c1d24a3e8cbab2 upstream. When passed -print-file-name=plugin, the dummy gcc script creates a temporary directory that is never cleaned up. To avoid cluttering $TMPDIR, instead use a static directory included in the source tree. Fixes: 76426e238834 ("kbuild: add dummy toolchains to enable all cc-option etc. in Kconfig") Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-08-21scripts/faddr2line: Fix vmlinux detection on arm64Josh Poimboeuf1-1/+3
[ Upstream commit b6a5068854cfe372da7dee3224dcf023ed5b00cb ] Since commit dcea997beed6 ("faddr2line: Fix overlapping text section failures, the sequel"), faddr2line is completely broken on arm64. For some reason, on arm64, the vmlinux ELF object file type is ET_DYN rather than ET_EXEC. Check for both when determining whether the object is vmlinux. Modules and vmlinux.o have type ET_REL on all arches. Fixes: dcea997beed6 ("faddr2line: Fix overlapping text section failures, the sequel") Reported-by: John Garry <john.garry@huawei.com> Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Tested-by: John Garry <john.garry@huawei.com> Link: https://lore.kernel.org/r/dad1999737471b06d6188ce4cdb11329aa41682c.1658426357.git.jpoimboe@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-07-25x86/retbleed: Add fine grained Kconfig knobsPeter Zijlstra2-1/+4
commit f43b9876e857c739d407bc56df288b0ebe1a9164 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: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Borislav Petkov <bp@suse.de> [cascardo: there is no CONFIG_OBJTOOL] [cascardo: objtool calling and option parsing has changed] 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-07-25objtool: Add entry UNRET validationPeter Zijlstra1-0/+3
commit a09a6e2399ba0595c3042b3164f3ca68a3cff33e upstream. Since entry asm is tricky, add a validation pass that ensures the retbleed mitigation has been done before the first actual RET instruction. Entry points are those that either have UNWIND_HINT_ENTRY, which acts as UNWIND_HINT_EMPTY but marks the instruction as an entry point, or those that have UWIND_HINT_IRET_REGS at +0. This is basically a variant of validate_branch() that is intra-function and it will simply follow all branches from marked entry points and ensures that all paths lead to ANNOTATE_UNRET_END. If a path hits RET or an indirection the path is a fail and will be reported. There are 3 ANNOTATE_UNRET_END instances: - UNTRAIN_RET itself - exception from-kernel; this path doesn't need UNTRAIN_RET - all early exceptions; these also don't need UNTRAIN_RET Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Josh Poimboeuf <jpoimboe@kernel.org> Signed-off-by: Borislav Petkov <bp@suse.de> [cascardo: arch/x86/entry/entry_64.S no pt_regs return at .Lerror_entry_done_lfence] [cascardo: tools/objtool/builtin-check.c no link option validation] [cascardo: tools/objtool/check.c opts.ibt is ibt] [cascardo: tools/objtool/include/objtool/builtin.h leave unret option as bool, no struct opts] [cascardo: objtool is still called from scripts/link-vmlinux.sh] [cascardo: no IBT support] Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> [bwh: Backported to 5.10: - In scripts/link-vmlinux.sh, use "test -n" instead of is_enabled - Adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-07-25x86: Add straight-line-speculation mitigationPeter Zijlstra2-0/+6
commit e463a09af2f0677b9485a7e8e4e70b396b2ffb6f upstream. Make use of an upcoming GCC feature to mitigate straight-line-speculation for x86: https://gcc.gnu.org/g:53a643f8568067d7700a9f2facc8ba39974973d3 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102952 https://bugs.llvm.org/show_bug.cgi?id=52323 It's built tested on x86_64-allyesconfig using GCC-12 and GCC-11. Maintenance overhead of this should be fairly low due to objtool validation. Size overhead of all these additional int3 instructions comes to: text data bss dec hex filename 22267751 6933356 2011368 31212475 1dc43bb defconfig-build/vmlinux 22804126 6933356 1470696 31208178 1dc32f2 defconfig-build/vmlinux.sls Or roughly 2.4% additional text. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lore.kernel.org/r/20211204134908.140103474@infradead.org Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [bwh: Backported to 5.10: - In scripts/Makefile.build, add the objtool option with an ifdef block, same as for other options - Adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-06-29modpost: fix section mismatch check for exported init/exit sectionsMasahiro Yamada1-1/+1
commit 28438794aba47a27e922857d27b31b74e8559143 upstream. Since commit f02e8a6596b7 ("module: Sort exported symbols"), EXPORT_SYMBOL* is placed in the individual section ___ksymtab(_gpl)+<sym> (3 leading underscores instead of 2). Since then, modpost cannot detect the bad combination of EXPORT_SYMBOL and __init/__exit. Fix the .fromsec field. Fixes: f02e8a6596b7 ("module: Sort exported symbols") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-06-22faddr2line: Fix overlapping text section failures, the sequelJosh Poimboeuf1-11/+34
[ Upstream commit dcea997beed694cbd8705100ca1a6eb0d886de69 ] If a function lives in a section other than .text, but .text also exists in the object, faddr2line may wrongly assume .text. This can result in comically wrong output. For example: $ scripts/faddr2line vmlinux.o enter_from_user_mode+0x1c enter_from_user_mode+0x1c/0x30: find_next_bit at /home/jpoimboe/git/linux/./include/linux/find.h:40 (inlined by) perf_clear_dirty_counters at /home/jpoimboe/git/linux/arch/x86/events/core.c:2504 Fix it by passing the section name to addr2line, unless the object file is vmlinux, in which case the symbol table uses absolute addresses. Fixes: 1d1a0e7c5100 ("scripts/faddr2line: Fix overlapping text section failures") Reported-by: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Link: https://lore.kernel.org/r/7d25bc1408bd3a750ac26e60d2f2815a5f4a8363.1654130536.git.jpoimboe@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-06-14scripts/gdb: change kernel config dumping methodKuan-Ying Lee1-3/+3
[ Upstream commit 1f7a6cf6b07c74a17343c2559cd5f5018a245961 ] MAGIC_START("IKCFG_ST") and MAGIC_END("IKCFG_ED") are moved out from the kernel_config_data variable. Thus, we parse kernel_config_data directly instead of considering offset of MAGIC_START and MAGIC_END. Fixes: 13610aa908dc ("kernel/configs: use .incbin directive to embed config_data.gz") Signed-off-by: Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-06-14modpost: fix undefined behavior of is_arm_mapping_symbol()Masahiro Yamada1-1/+2
[ Upstream commit d6b732666a1bae0df3c3ae06925043bba34502b1 ] The return value of is_arm_mapping_symbol() is unpredictable when "$" is passed in. strchr(3) says: The strchr() and strrchr() functions return a pointer to the matched character or NULL if the character is not found. The terminating null byte is considered part of the string, so that if c is specified as '\0', these functions return a pointer to the terminator. When str[1] is '\0', strchr("axtd", str[1]) is not NULL, and str[2] is referenced (i.e. buffer overrun). Test code --------- char str1[] = "abc"; char str2[] = "ab"; strcpy(str1, "$"); strcpy(str2, "$"); printf("test1: %d\n", is_arm_mapping_symbol(str1)); printf("test2: %d\n", is_arm_mapping_symbol(str2)); Result ------ test1: 0 test2: 1 Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-06-14modpost: fix removing numeric suffixesAlexander Lobakin1-1/+1
[ Upstream commit b5beffa20d83c4e15306c991ffd00de0d8628338 ] With the `-z unique-symbol` linker flag or any similar mechanism, it is possible to trigger the following: ERROR: modpost: "param_set_uint.0" [vmlinux] is a static EXPORT_SYMBOL The reason is that for now the condition from remove_dot(): if (m && (s[n + m] == '.' || s[n + m] == 0)) which was designed to test if it's a dot or a '\0' after the suffix is never satisfied. This is due to that `s[n + m]` always points to the last digit of a numeric suffix, not on the symbol next to it (from a custom debug print added to modpost): param_set_uint.0, s[n + m] is '0', s[n + m + 1] is '\0' So it's off-by-one and was like that since 2014. Fix this for the sake of any potential upcoming features, but don't bother stable-backporting, as it's well hidden -- apart from that LD flag, it can be triggered only with GCC LTO which never landed upstream. Fixes: fcd38ed0ff26 ("scripts: modpost: fix compilation warning") Signed-off-by: Alexander Lobakin <alexandr.lobakin@intel.com> Reviewed-by: Petr Mladek <pmladek@suse.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-06-09scripts/faddr2line: Fix overlapping text section failuresJosh Poimboeuf1-53/+97
[ Upstream commit 1d1a0e7c5100d332583e20b40aa8c0a8ed3d7849 ] There have been some recent reports of faddr2line failures: $ scripts/faddr2line sound/soundcore.ko sound_devnode+0x5/0x35 bad symbol size: base: 0x0000000000000000 end: 0x0000000000000000 $ ./scripts/faddr2line vmlinux.o enter_from_user_mode+0x24 bad symbol size: base: 0x0000000000005fe0 end: 0x0000000000005fe0 The problem is that faddr2line is based on 'nm', which has a major limitation: it doesn't know how to distinguish between different text sections. So if an offset exists in multiple text sections in the object, it may fail. Rewrite faddr2line to be section-aware, by basing it on readelf. Fixes: 67326666e2d4 ("scripts: add script for translating stack dump function offsets") Reported-by: Kaiwan N Billimoria <kaiwan.billimoria@gmail.com> Reported-by: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Link: https://lore.kernel.org/r/29ff99f86e3da965b6e46c1cc2d72ce6528c17c3.1652382321.git.jpoimboe@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-20gcc-plugins: latent_entropy: use /dev/urandomJason A. Donenfeld1-17/+27
commit c40160f2998c897231f8454bf797558d30a20375 upstream. While the latent entropy plugin mostly doesn't derive entropy from get_random_const() for measuring the call graph, when __latent_entropy is applied to a constant, then it's initialized statically to output from get_random_const(). In that case, this data is derived from a 64-bit seed, which means a buffer of 512 bits doesn't really have that amount of compile-time entropy. This patch fixes that shortcoming by just buffering chunks of /dev/urandom output and doling it out as requested. At the same time, it's important that we don't break the use of -frandom-seed, for people who want the runtime benefits of the latent entropy plugin, while still having compile-time determinism. In that case, we detect whether gcc's set_random_seed() has been called by making a call to get_random_seed(noinit=true) in the plugin init function, which is called after set_random_seed() is called but before anything that calls get_random_seed(noinit=false), and seeing if it's zero or not. If it's not zero, we're in deterministic mode, and so we just generate numbers with a basic xorshift prng. Note that we don't detect if -frandom-seed is being used using the documented local_tick variable, because it's assigned via: local_tick = (unsigned) tv.tv_sec * 1000 + tv.tv_usec / 1000; which may well overflow and become -1 on its own, and so isn't reliable: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105171 [kees: The 256 byte rnd_buf size was chosen based on average (250), median (64), and std deviation (575) bytes of used entropy for a defconfig x86_64 build] Fixes: 38addce8b600 ("gcc-plugins: Add latent_entropy plugin") Cc: stable@vger.kernel.org Cc: PaX Team <pageexec@freemail.hu> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20220405222815.21155-1-Jason@zx2c4.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-13ubsan: remove CONFIG_UBSAN_OBJECT_SIZEKees Cook1-1/+0
commit 69d0db01e210e07fe915e5da91b54a867cda040f upstream. The object-size sanitizer is redundant to -Warray-bounds, and inappropriately performs its checks at run-time when all information needed for the evaluation is available at compile-time, making it quite difficult to use: https://bugzilla.kernel.org/show_bug.cgi?id=214861 With -Warray-bounds almost enabled globally, it doesn't make sense to keep this around. Link: https://lkml.kernel.org/r/20211203235346.110809-1-keescook@chromium.org Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Marco Elver <elver@google.com> Cc: Masahiro Yamada <masahiroy@kernel.org> Cc: Michal Marek <michal.lkml@markovi.net> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Nathan Chancellor <nathan@kernel.org> Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com> Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Tadeusz Struk <tadeusz.struk@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-08gcc-plugins/stackleak: Exactly match strings instead of prefixesKees Cook1-4/+21
[ Upstream commit 27e9faf415dbf94af19b9c827842435edbc1fbbc ] Since STRING_CST may not be NUL terminated, strncmp() was used for check for equality. However, this may lead to mismatches for longer section names where the start matches the tested-for string. Test for exact equality by checking for the presences of NUL termination. Cc: Alexander Popov <alex.popov@linux.com> Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-08scripts/dtc: Call pkg-config POSIXly correctThomas Bracht Laumann Jespersen1-1/+1
[ Upstream commit a8b309ce9760943486e0585285e0125588a31650 ] Running with POSIXLY_CORRECT=1 in the environment the scripts/dtc build fails, because pkg-config doesn't output anything when the flags come after the arguments. Fixes: 067c650c456e ("dtc: Use pkg-config to locate libyaml") Signed-off-by: Thomas Bracht Laumann Jespersen <t@laumann.xyz> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20220131112028.7907-1-t@laumann.xyz Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-02-23kconfig: fix failing to generate auto.confJing Leng1-4/+9
[ Upstream commit 1b9e740a81f91ae338b29ed70455719804957b80 ] When the KCONFIG_AUTOCONFIG is specified (e.g. export \ KCONFIG_AUTOCONFIG=output/config/auto.conf), the directory of include/config/ will not be created, so kconfig can't create deps files in it and auto.conf can't be generated. Signed-off-by: Jing Leng <jleng@ambarella.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-02-23kconfig: let 'shell' return enough output for deep path namesBrenda Streiff1-1/+1
[ Upstream commit 8a4c5b2a6d8ea079fa36034e8167de87ab6f8880 ] The 'shell' built-in only returns the first 256 bytes of the command's output. In some cases, 'shell' is used to return a path; by bumping up the buffer size to 4096 this lets us capture up to PATH_MAX. The specific case where I ran into this was due to commit 1e860048c53e ("gcc-plugins: simplify GCC plugin-dev capability test"). After this change, we now use `$(shell,$(CC) -print-file-name=plugin)` to return a path; if the gcc path is particularly long, then the path ends up truncated at the 256 byte mark, which makes the HAVE_GCC_PLUGINS depends test always fail. Signed-off-by: Brenda Streiff <brenda.streiff@ni.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-02-23kbuild: lto: Merge module sections if and only if CONFIG_LTO_CLANG is enabledSean Christopherson1-0/+2
commit 6a3193cdd5e5b96ac65f04ee42555c216da332af upstream. Merge module sections only when using Clang LTO. With ld.bfd, merging sections does not appear to update the symbol tables for the module, e.g. 'readelf -s' shows the value that a symbol would have had, if sections were not merged. ld.lld does not show this problem. The stale symbol table breaks gdb's function disassembler, and presumably other things, e.g. gdb -batch -ex "file arch/x86/kvm/kvm.ko" -ex "disassemble kvm_init" reads the wrong bytes and dumps garbage. Fixes: dd2776222abb ("kbuild: lto: merge module sections") Cc: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Sami Tolvanen <samitolvanen@google.com> Tested-by: Sami Tolvanen <samitolvanen@google.com> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20210322234438.502582-1-seanjc@google.com Cc: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-23kbuild: lto: merge module sectionsSami Tolvanen1-0/+24
commit dd2776222abb9893e5b5c237a2c8c880d8854cee upstream. LLD always splits sections with LTO, which increases module sizes. This change adds linker script rules to merge the split sections in the final module. Suggested-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20201211184633.3213045-6-samitolvanen@google.com Cc: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-16Makefile.extrawarn: Move -Wunaligned-access to W=1Nathan Chancellor1-0/+1
commit 1cf5f151d25fcca94689efd91afa0253621fb33a upstream. -Wunaligned-access is a new warning in clang that is default enabled for arm and arm64 under certain circumstances within the clang frontend (see LLVM commit below). On v5.17-rc2, an ARCH=arm allmodconfig build shows 1284 total/70 unique instances of this warning (most of the instances are in header files), which is quite noisy. To keep a normal build green through CONFIG_WERROR, only show this warning with W=1, which will allow automated build systems to catch new instances of the warning so that the total number can be driven down to zero eventually since catching unaligned accesses at compile time would be generally useful. Cc: stable@vger.kernel.org Link: https://github.com/llvm/llvm-project/commit/35737df4dcd28534bd3090157c224c19b501278a Link: https://github.com/ClangBuiltLinux/linux/issues/1569 Link: https://github.com/ClangBuiltLinux/linux/issues/1576 Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-01-27scripts: sphinx-pre-install: Fix ctex support on DebianMauro Carvalho Chehab1-0/+3
commit 87d6576ddf8ac25f36597bc93ca17f6628289c16 upstream. The name of the package with ctexhook.sty is different on Debian/Ubuntu. Reported-by: Akira Yokosawa <akiyks@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Tested-by: Akira Yokosawa <akiyks@gmail.com> Link: https://lore.kernel.org/r/63882425609a2820fac78f5e94620abeb7ed5f6f.1641429634.git.mchehab@kernel.org Signed-off-by: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-01-27scripts: sphinx-pre-install: add required ctex dependencyMauro Carvalho Chehab1-0/+1
commit 7baab965896eaeea60a54b8fe742feea2f79060f upstream. After a change meant to fix support for oriental characters (Chinese, Japanese, Korean), ctex stylesheet is now a requirement for PDF output. Reported-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Link: https://lore.kernel.org/r/165aa6167f21e3892a6e308688c93c756e94f4e0.1641243581.git.mchehab@kernel.org Signed-off-by: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-01-27scripts/dtc: dtx_diff: remove broken example from help textMatthias Schiffer1-6/+2
commit d8adf5b92a9d2205620874d498c39923ecea8749 upstream. dtx_diff suggests to use <(...) syntax to pipe two inputs into it, but this has never worked: The /proc/self/fds/... paths passed by the shell will fail the `[ -f "${dtx}" ] && [ -r "${dtx}" ]` check in compile_to_dts, but even with this check removed, the function cannot work: hexdump will eat up the DTB magic, making the subsequent dtc call fail, as a pipe cannot be rewound. Simply remove this broken example, as there is already an alternative one that works fine. Fixes: 10eadc253ddf ("dtc: create tool to diff device trees") Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Reviewed-by: Frank Rowand <frank.rowand@sony.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20220113081918.10387-1-matthias.schiffer@ew.tq-group.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-01-05recordmcount.pl: fix typo in s390 mcount regexHeiko Carstens1-1/+1
commit 4eb1782eaa9fa1c224ad1fa0d13a9f09c3ab2d80 upstream. Commit 85bf17b28f97 ("recordmcount.pl: look for jgnop instruction as well as bcrl on s390") added a new alternative mnemonic for the existing brcl instruction. This is required for the combination old gcc version (pre 9.0) and binutils since version 2.37. However at the same time this commit introduced a typo, replacing brcl with bcrl. As a result no mcount locations are detected anymore with old gcc versions (pre 9.0) and binutils before version 2.37. Fix this by using the correct mnemonic again. Reported-by: Miroslav Benes <mbenes@suse.cz> Cc: Jerome Marchand <jmarchan@redhat.com> Cc: <stable@vger.kernel.org> Fixes: 85bf17b28f97 ("recordmcount.pl: look for jgnop instruction as well as bcrl on s390") Link: https://lore.kernel.org/r/alpine.LSU.2.21.2112230949520.19849@pobox.suse.cz Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-22recordmcount.pl: look for jgnop instruction as well as bcrl on s390Jerome Marchand1-1/+1
commit 85bf17b28f97ca2749968d8786dc423db320d9c2 upstream. On s390, recordmcount.pl is looking for "bcrl 0,<xxx>" instructions in the objdump -d outpout. However since binutils 2.37, objdump -d display "jgnop <xxx>" for the same instruction. Update the mcount_regex so that it accepts both. Signed-off-by: Jerome Marchand <jmarchan@redhat.com> Reviewed-by: Miroslav Benes <mbenes@suse.cz> Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20211210093827.1623286-1-jmarchan@redhat.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-14kbuild: simplify GCC_PLUGINS enablement in dummy-tools/gccMasahiro Yamada1-7/+3
commit f4c3b83b75b91c5059726cb91e3165cc01764ce7 upstream. With commit 1e860048c53e ("gcc-plugins: simplify GCC plugin-dev capability test") applied, this hunk can be way simplified because now scripts/gcc-plugins/Kconfig only checks plugin-version.h Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-14gcc-plugins: fix gcc 11 indigestion with plugins...Valdis Kletnieks1-2/+2
commit 67a5a68013056cbcf0a647e36cb6f4622fb6a470 upstream. Fedora Rawhide has started including gcc 11,and the g++ compiler throws a wobbly when it hits scripts/gcc-plugins: HOSTCXX scripts/gcc-plugins/latent_entropy_plugin.so In file included from /usr/include/c++/11/type_traits:35, from /usr/lib/gcc/x86_64-redhat-linux/11/plugin/include/system.h:244, from /usr/lib/gcc/x86_64-redhat-linux/11/plugin/include/gcc-plugin.h:28, from scripts/gcc-plugins/gcc-common.h:7, from scripts/gcc-plugins/latent_entropy_plugin.c:78: /usr/include/c++/11/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support must be enabled with the -std=c++11 or -std=gnu++11 compiler options. 32 | #error This file requires compiler and library support \ In fact, it works just fine with c++11, which has been in gcc since 4.8, and we now require 4.9 as a minimum. Signed-off-by: Valdis Kletnieks <valdis.kletnieks@vt.edu> Acked-by: Josh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/82487.1609006918@turing-police Cc: Thomas Lindroth <thomas.lindroth@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-14gcc-plugins: simplify GCC plugin-dev capability testMasahiro Yamada2-20/+1
commit 1e860048c53ee77ee9870dcce94847a28544b753 upstream. Linus pointed out a third of the time in the Kconfig parse stage comes from the single invocation of cc1plus in scripts/gcc-plugin.sh [1], and directly testing plugin-version.h for existence cuts down the overhead a lot. [2] This commit takes one step further to kill the build test entirely. The small piece of code was probably intended to test the C++ designated initializer, which was not supported until C++20. In fact, with -pedantic option given, both GCC and Clang emit a warning. $ echo 'class test { public: int test; } test = { .test = 1 };' | g++ -x c++ -pedantic - -fsyntax-only <stdin>:1:43: warning: C++ designated initializers only available with '-std=c++2a' or '-std=gnu++2a' [-Wpedantic] $ echo 'class test { public: int test; } test = { .test = 1 };' | clang++ -x c++ -pedantic - -fsyntax-only <stdin>:1:43: warning: designated initializers are a C++20 extension [-Wc++20-designator] class test { public: int test; } test = { .test = 1 }; ^ 1 warning generated. Otherwise, modern C++ compilers should be able to build the code, and hopefully skipping this test should not make any practical problem. Checking the existence of plugin-version.h is still needed to ensure the plugin-dev package is installed. The test code is now small enough to be embedded in scripts/gcc-plugins/Kconfig. [1] https://lore.kernel.org/lkml/CAHk-=wjU4DCuwQ4pXshRbwDCUQB31ScaeuDo1tjoZ0_PjhLHzQ@mail.gmail.com/ [2] https://lore.kernel.org/lkml/CAHk-=whK0aQxs6Q5ijJmYF1n2ch8cVFSUzU5yUM_HOjig=+vnw@mail.gmail.com/ Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20201203125700.161354-1-masahiroy@kernel.org Cc: Thomas Lindroth <thomas.lindroth@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-21scripts/lld-version.sh: Rewrite based on upstream ld-version.shNathan Chancellor1-9/+26
This patch is for linux-5.10.y only. When scripts/lld-version.sh was initially written, it did not account for the LLD_VENDOR cmake flag, which changes the output of ld.lld's --version flag slightly. Without LLD_VENDOR: $ ld.lld --version LLD 14.0.0 (compatible with GNU linkers) With LLD_VENDOR: $ ld.lld --version Debian LLD 14.0.0 (compatible with GNU linkers) As a result, CONFIG_LLD_VERSION is messed up and configuration values that are dependent on it cannot be selected: scripts/lld-version.sh: 20: printf: LLD: expected numeric value scripts/lld-version.sh: 20: printf: LLD: expected numeric value scripts/lld-version.sh: 20: printf: LLD: expected numeric value init/Kconfig:52:warning: 'LLD_VERSION': number is invalid .config:11:warning: symbol value '00000' invalid for LLD_VERSION .config:8800:warning: override: CPU_BIG_ENDIAN changes choice state This was fixed upstream by commit 1f09af062556 ("kbuild: Fix ld-version.sh script if LLD was built with LLD_VENDOR") in 5.12 but that was done to ld-version.sh after it was massively rewritten in commit 02aff8592204 ("kbuild: check the minimum linker version in Kconfig"). To avoid bringing in that change plus its prerequisites and fixes, just modify lld-version.sh to make it similar to the upstream ld-version.sh, which handles ld.lld with or without LLD_VENDOR and ld.bfd without any errors. Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18leaking_addresses: Always print a trailing newlineKees Cook1-1/+2
[ Upstream commit cf2a85efdade117e2169d6e26641016cbbf03ef0 ] For files that lack trailing newlines and match a leaking address (e.g. wchan[1]), the leaking_addresses.pl report would run together with the next line, making things look corrupted. Unconditionally remove the newline on input, and write it back out on output. [1] https://lore.kernel.org/all/20210103142726.GC30643@xsang-OptiPlex-9020/ Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20211008111626.151570317@infradead.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-27gcc-plugins/structleak: add makefile var for disabling structleakBrendan Higgins1-0/+4
[ Upstream commit 554afc3b9797511e3245864e32aebeb6abbab1e3 ] KUnit and structleak don't play nice, so add a makefile variable for enabling structleak when it complains. Co-developed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Brendan Higgins <brendanhiggins@google.com> Reviewed-by: David Gow <davidgow@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-20nds32/ftrace: Fix Error: invalid operands (*UND* and *UND* sections) for `^'Steven Rostedt1-1/+1
commit be358af1191b1b2fedebd8f3421cafdc8edacc7d upstream. I received a build failure for a new patch I'm working on the nds32 architecture, and when I went to test it, I couldn't get to my build error, because it failed to build with a bunch of: Error: invalid operands (*UND* and *UND* sections) for `^' issues with various files. Those files were temporary asm files that looked like: kernel/.tmp_mc_fork.s I decided to look deeper, and found that the "mc" portion of that name stood for "mcount", and was created by the recordmcount.pl script. One that I wrote over a decade ago. Once I knew the source of the problem, I was able to investigate it further. The way the recordmcount.pl script works (BTW, there's a C version that simply modifies the ELF object) is by doing an "objdump" on the object file. Looks for all the calls to "mcount", and creates an offset of those locations from some global variable it can use (usually a global function name, found with <.*>:). Creates a asm file that is a table of references to these locations, using the found variable/function. Compiles it and links it back into the original object file. This asm file is called ".tmp_mc_<object_base_name>.s". The problem here is that the objdump produced by the nds32 object file, contains things that look like: 0000159a <.L3^B1>: 159a: c6 00 beqz38 $r6, 159a <.L3^B1> 159a: R_NDS32_9_PCREL_RELA .text+0x159e 159c: 84 d2 movi55 $r6, #-14 159e: 80 06 mov55 $r0, $r6 15a0: ec 3c addi10.sp #0x3c Where ".L3^B1 is somehow selected as the "global" variable to index off of. Then the assembly file that holds the mcount locations looks like this: .section __mcount_loc,"a",@progbits .align 2 .long .L3^B1 + -5522 .long .L3^B1 + -5384 .long .L3^B1 + -5270 .long .L3^B1 + -5098 .long .L3^B1 + -4970 .long .L3^B1 + -4758 .long .L3^B1 + -4122 [...] And when it is compiled back to an object to link to the original object, the compile fails on the "^" symbol. Simple solution for now, is to have the perl script ignore using function symbols that have an "^" in the name. Link: https://lkml.kernel.org/r/20211014143507.4ad2c0f7@gandalf.local.home Cc: stable@vger.kernel.org Acked-by: Greentime Hu <green.hu@gmail.com> Fixes: fbf58a52ac088 ("nds32/ftrace: Add RECORD_MCOUNT support") Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-22gen_compile_commands: fix missing 'sys' packageKortan1-0/+1
commit ec783c7cb2495c5a3b8ca10db8056d43c528f940 upstream. We need to import the 'sys' package since the script has called sys.exit() method. Fixes: 6ad7cbc01527 ("Makefile: Add clang-tidy and static analyzer support to makefile") Signed-off-by: Kortan <kortanzh@gmail.com> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-18kbuild: Fix 'no symbols' warning when CONFIG_TRIM_UNUSD_KSYMS=yMasahiro Yamada1-1/+7
[ Upstream commit 52d83df682c82055961531853c066f4f16e234ea ] When CONFIG_TRIM_UNUSED_KSYMS is enabled, I see some warnings like this: nm: arch/x86/entry/vdso/vdso32/note.o: no symbols $NM (both GNU nm and llvm-nm) warns when no symbol is found in the object. Suppress the stderr. Fangrui Song mentioned binutils>=2.37 `nm -q` can be used to suppress "no symbols" [1], and llvm-nm>=13.0.0 supports -q as well. We cannot use it for now, but note it as a TODO. [1]: https://sourceware.org/bugzilla/show_bug.cgi?id=27408 Fixes: bbda5ec671d3 ("kbuild: simplify dependency generation for CONFIG_TRIM_UNUSED_KSYMS") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-08-12scripts/tracing: fix the bug that can't parse raw_trace_funcHui Su1-3/+3
commit 1c0cec64a7cc545eb49f374a43e9f7190a14defa upstream. Since commit 77271ce4b2c0 ("tracing: Add irq, preempt-count and need resched info to default trace output"), the default trace output format has been changed to: <idle>-0 [009] d.h. 22420.068695: _raw_spin_lock_irqsave <-hrtimer_interrupt <idle>-0 [000] ..s. 22420.068695: _nohz_idle_balance <-run_rebalance_domains <idle>-0 [011] d.h. 22420.068695: account_process_tick <-update_process_times origin trace output format:(before v3.2.0) # tracer: nop # # TASK-PID CPU# TIMESTAMP FUNCTION # | | | | | migration/0-6 [000] 50.025810: rcu_note_context_switch <-__schedule migration/0-6 [000] 50.025812: trace_rcu_utilization <-rcu_note_context_switch migration/0-6 [000] 50.025813: rcu_sched_qs <-rcu_note_context_switch migration/0-6 [000] 50.025815: rcu_preempt_qs <-rcu_note_context_switch migration/0-6 [000] 50.025817: trace_rcu_utilization <-rcu_note_context_switch migration/0-6 [000] 50.025818: debug_lockdep_rcu_enabled <-__schedule migration/0-6 [000] 50.025820: debug_lockdep_rcu_enabled <-__schedule The draw_functrace.py(introduced in v2.6.28) can't parse the new version format trace_func, So we need modify draw_functrace.py to adapt the new version trace output format. Link: https://lkml.kernel.org/r/20210611022107.608787-1-suhui@zeku.com Cc: stable@vger.kernel.org Fixes: 77271ce4b2c0 tracing: Add irq, preempt-count and need resched info to default trace output Signed-off-by: Hui Su <suhui@zeku.com> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-25kbuild: mkcompile_h: consider timestamp if KBUILD_BUILD_TIMESTAMP is setMatthias Maennich1-3/+11
[ Upstream commit a979522a1a88556e42a22ce61bccc58e304cb361 ] To avoid unnecessary recompilations, mkcompile_h does not regenerate compile.h if just the timestamp changed. Though, if KBUILD_BUILD_TIMESTAMP is set, an explicit timestamp for the build was requested, in which case we should not ignore it. If a user follows the documentation for reproducible builds [1] and defines KBUILD_BUILD_TIMESTAMP as the git commit timestamp, a clean build will have the correct timestamp. A subsequent cherry-pick (or amend) changes the commit timestamp and if an incremental build is done with a different KBUILD_BUILD_TIMESTAMP now, that new value is not taken into consideration. But it should for reproducibility. Hence, whenever KBUILD_BUILD_TIMESTAMP is explicitly set, do not ignore UTS_VERSION when making a decision about whether the regenerated version of compile.h should be moved into place. [1] https://www.kernel.org/doc/html/latest/kbuild/reproducible-builds.html Signed-off-by: Matthias Maennich <maennich@google.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-25kbuild: sink stdout from cmd for silent buildMasahiro Yamada1-1/+6
[ Upstream commit 174a1dcc96429efce4ef7eb2f5c4506480da2182 ] When building with 'make -s', no output to stdout should be printed. As Arnd Bergmann reported [1], mkimage shows the detailed information of the generated images. I think this should be suppressed by the 'cmd' macro instead of by individual scripts. Insert 'exec >/dev/null;' in order to redirect stdout to /dev/null for silent builds. [Note about this implementation] 'exec >/dev/null;' may look somewhat tricky, but this has a reason. Appending '>/dev/null' at the end of command line is a common way for redirection, so I first tried this: cmd = @set -e; $(echo-cmd) $(cmd_$(1)) >/dev/null ... but it would not work if $(cmd_$(1)) itself contains a redirection. For example, cmd_wrap in scripts/Makefile.asm-generic redirects the output from the 'echo' command into the target file. It would be expanded into: echo "#include <asm-generic/$*.h>" > $@ >/dev/null Then, the target file gets empty because the string will go to /dev/null instead of $@. Next, I tried this: cmd = @set -e; $(echo-cmd) { $(cmd_$(1)); } >/dev/null The form above would be expanded into: { echo "#include <asm-generic/$*.h>" > $@; } >/dev/null This works as expected. However, it would be a syntax error if $(cmd_$(1)) is empty. When CONFIG_TRIM_UNUSED_KSYMS is disabled, $(call cmd,gen_ksymdeps) in scripts/Makefile.build would be expanded into: set -e; { ; } >/dev/null ..., which causes an syntax error. I also tried this: cmd = @set -e; $(echo-cmd) ( $(cmd_$(1)) ) >/dev/null ... but this causes a syntax error for the same reason. So, finally I adopted: cmd = @set -e; $(echo-cmd) exec >/dev/null; $(cmd_$(1)) [1]: https://lore.kernel.org/lkml/20210514135752.2910387-1-arnd@kernel.org/ Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-14kbuild: Fix objtool dependency for 'OBJECT_FILES_NON_STANDARD_<obj> := n'Josh Poimboeuf1-2/+3
[ Upstream commit 8852c552402979508fdc395ae07aa8761aa46045 ] "OBJECT_FILES_NON_STANDARD_vma.o := n" has a dependency bug. When objtool source is updated, the affected object doesn't get re-analyzed by objtool. Peter's new variable-sized jump label feature relies on objtool rewriting the object file. Otherwise the system can fail to boot. That effectively upgrades this minor dependency issue to a major bug. The problem is that variables in prerequisites are expanded early, during the read-in phase. The '$(objtool_dep)' variable indirectly uses '$@', which isn't yet available when the target prerequisites are evaluated. Use '.SECONDEXPANSION:' which causes '$(objtool_dep)' to be expanded in a later phase, after the target-specific '$@' variable has been defined. Fixes: b9ab5ebb14ec ("objtool: Add CONFIG_STACK_VALIDATION option") Fixes: ab3257042c26 ("jump_label, x86: Allow short NOPs") Reported-by: Matthew Wilcox <willy@infradead.org> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-14Makefile: fix GDB warning with CONFIG_RELRNick Desaulniers1-1/+2
[ Upstream commit 27f2a4db76e8d8a8b601fc1c6a7a17f88bd907ab ] GDB produces the following warning when debugging kernels built with CONFIG_RELR: BFD: /android0/linux-next/vmlinux: unknown type [0x13] section `.relr.dyn' when loading a kernel built with CONFIG_RELR into GDB. It can also prevent debugging symbols using such relocations. Peter sugguests: [That flag] means that lld will use dynamic tags and section type numbers in the OS-specific range rather than the generic range. The kernel itself doesn't care about these numbers; it determines the location of the RELR section using symbols defined by a linker script. Link: https://github.com/ClangBuiltLinux/linux/issues/1057 Suggested-by: Peter Collingbourne <pcc@google.com> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Link: https://lore.kernel.org/r/20210522012626.2811297-1-ndesaulniers@google.com Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-06-30certs: Add ability to preload revocation certsEric Snowberg1-0/+1
[ Upstream commit d1f044103dad70c1cec0a8f3abdf00834fec8b98 ] Add a new Kconfig option called SYSTEM_REVOCATION_KEYS. If set, this option should be the filename of a PEM-formated file containing X.509 certificates to be included in the default blacklist keyring. DH Changes: - Make the new Kconfig option depend on SYSTEM_REVOCATION_LIST. - Fix SYSTEM_REVOCATION_KEYS=n, but CONFIG_SYSTEM_REVOCATION_LIST=y[1][2]. - Use CONFIG_SYSTEM_REVOCATION_LIST for extract-cert[3]. - Use CONFIG_SYSTEM_REVOCATION_LIST for revocation_certificates.o[3]. Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com> Acked-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: David Howells <dhowells@redhat.com> cc: Randy Dunlap <rdunlap@infradead.org> cc: keyrings@vger.kernel.org Link: https://lore.kernel.org/r/e1c15c74-82ce-3a69-44de-a33af9b320ea@infradead.org/ [1] Link: https://lore.kernel.org/r/20210303034418.106762-1-eric.snowberg@oracle.com/ [2] Link: https://lore.kernel.org/r/20210304175030.184131-1-eric.snowberg@oracle.com/ [3] Link: https://lore.kernel.org/r/20200930201508.35113-3-eric.snowberg@oracle.com/ Link: https://lore.kernel.org/r/20210122181054.32635-4-eric.snowberg@oracle.com/ # v5 Link: https://lore.kernel.org/r/161428673564.677100.4112098280028451629.stgit@warthog.procyon.org.uk/ Link: https://lore.kernel.org/r/161433312452.902181.4146169951896577982.stgit@warthog.procyon.org.uk/ # v2 Link: https://lore.kernel.org/r/161529606657.163428.3340689182456495390.stgit@warthog.procyon.org.uk/ # v3 Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-06-30recordmcount: Correct st_shndx handlingPeter Zijlstra1-5/+10
[ Upstream commit fb780761e7bd9f2e94f5b9a296ead6b35b944206 ] One should only use st_shndx when >SHN_UNDEF and <SHN_LORESERVE. When SHN_XINDEX, then use .symtab_shndx. Otherwise use 0. This handles the case: st_shndx >= SHN_LORESERVE && st_shndx != SHN_XINDEX. Link: https://lore.kernel.org/lkml/20210607023839.26387-1-mark-pk.tsai@mediatek.com/ Link: https://lkml.kernel.org/r/20210616154126.2794-1-mark-pk.tsai@mediatek.com Reported-by: Mark-PK Tsai <mark-pk.tsai@mediatek.com> Tested-by: Mark-PK Tsai <mark-pk.tsai@mediatek.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> [handle endianness of sym->st_shndx] Signed-off-by: Mark-PK Tsai <mark-pk.tsai@mediatek.com> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-06-03scripts/clang-tools: switch explicitly to Python 3Masahiro Yamada2-2/+2
commit 074075aea2ff72dade5231b4ee9f2ab9a055f1ec upstream. For the same reason as commit 51839e29cb59 ("scripts: switch explicitly to Python 3"), switch some more scripts, which I tested and confirmed working on Python 3. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Acked-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-22scripts: switch explicitly to Python 3Andy Shevchenko2-2/+2
commit 51839e29cb5954470ea4db7236ef8c3d77a6e0bb upstream. Some distributions are about to switch to Python 3 support only. This means that /usr/bin/python, which is Python 2, is not available anymore. Hence, switch scripts to use Python 3 explicitly. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-22tweewide: Fix most Shebang linesFinn Behrens8-8/+8
commit c25ce589dca10d64dde139ae093abc258a32869c upstream. Change every shebang which does not need an argument to use /usr/bin/env. This is needed as not every distro has everything under /usr/bin, sometimes not even bash. Signed-off-by: Finn Behrens <me@kloenk.de> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-22riscv: Workaround mcount name prior to clang-13Nathan Chancellor1-1/+1
[ Upstream commit 7ce04771503074a7de7f539cc43f5e1b385cb99b ] Prior to clang 13.0.0, the RISC-V name for the mcount symbol was "mcount", which differs from the GCC version of "_mcount", which results in the following errors: riscv64-linux-gnu-ld: init/main.o: in function `__traceiter_initcall_level': main.c:(.text+0xe): undefined reference to `mcount' riscv64-linux-gnu-ld: init/main.o: in function `__traceiter_initcall_start': main.c:(.text+0x4e): undefined reference to `mcount' riscv64-linux-gnu-ld: init/main.o: in function `__traceiter_initcall_finish': main.c:(.text+0x92): undefined reference to `mcount' riscv64-linux-gnu-ld: init/main.o: in function `.LBB32_28': main.c:(.text+0x30c): undefined reference to `mcount' riscv64-linux-gnu-ld: init/main.o: in function `free_initmem': main.c:(.text+0x54c): undefined reference to `mcount' This has been corrected in https://reviews.llvm.org/D98881 but the minimum supported clang version is 10.0.1. To avoid build errors and to gain a working function tracer, adjust the name of the mcount symbol for older versions of clang in mount.S and recordmcount.pl. Link: https://github.com/ClangBuiltLinux/linux/issues/1331 Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-22scripts/recordmcount.pl: Fix RISC-V regex for clangNathan Chancellor1-1/+1
[ Upstream commit 2f095504f4b9cf75856d6a9cf90299cf75aa46c5 ] Clang can generate R_RISCV_CALL_PLT relocations to _mcount: $ llvm-objdump -dr build/riscv/init/main.o | rg mcount 000000000000000e: R_RISCV_CALL_PLT _mcount 000000000000004e: R_RISCV_CALL_PLT _mcount After this, the __start_mcount_loc section is properly generated and function tracing still works. Link: https://github.com/ClangBuiltLinux/linux/issues/1331 Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Fangrui Song <maskray@google.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-19kbuild: generate Module.symvers only when vmlinux existsMasahiro Yamada2-15/+15
[ Upstream commit 69bc8d386aebbd91a6bb44b6d33f77c8dfa9ed8c ] The external module build shows the following warning if Module.symvers is missing in the kernel tree. WARNING: Symbol version dump "Module.symvers" is missing. Modules may not have dependencies or modversions. I think this is an important heads-up because the resulting modules may not work as expected. This happens when you did not build the entire kernel tree, for example, you might have prepared the minimal setups for external modules by 'make defconfig && make modules_preapre'. A problem is that 'make modules' creates Module.symvers even without vmlinux. In this case, that warning is suppressed since Module.symvers already exists in spite of its incomplete content. The incomplete (i.e. invalid) Module.symvers should not be created. This commit changes the second pass of modpost to dump symbols into modules-only.symvers. The final Module.symvers is created by concatenating vmlinux.symvers and modules-only.symvers if both exist. Module.symvers is supposed to collect symbols from both vmlinux and modules. It might be a bit confusing, and I am not quite sure if it is an official interface, but presumably it is difficult to rename it because some tools (e.g. kmod) parse it. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-19kconfig: nconf: stop endless search loopsMihai Moldovan1-1/+1
[ Upstream commit 8c94b430b9f6213dec84e309bb480a71778c4213 ] If the user selects the very first entry in a page and performs a search-up operation, or selects the very last entry in a page and performs a search-down operation that will not succeed (e.g., via [/]asdfzzz[Up Arrow]), nconf will never terminate searching the page. The reason is that in this case, the starting point will be set to -1 or n, which is then translated into (n - 1) (i.e., the last entry of the page) or 0 (i.e., the first entry of the page) and finally the search begins. This continues to work fine until the index reaches 0 or (n - 1), at which point it will be decremented to -1 or incremented to n, but not checked against the starting point right away. Instead, it's wrapped around to the bottom or top again, after which the starting point check occurs... and naturally fails. My original implementation added another check for -1 before wrapping the running index variable around, but Masahiro Yamada pointed out that the actual issue is that the comparison point (starting point) exceeds bounds (i.e., the [0,n-1] interval) in the first place and that, instead, the starting point should be fixed. This has the welcome side-effect of also fixing the case where the starting point was n while searching down, which also lead to an infinite loop. OTOH, this code is now essentially all his work. Amazingly, nobody seems to have been hit by this for 11 years - or at the very least nobody bothered to debug and fix this. Signed-off-by: Mihai Moldovan <ionic@ionic.de> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-04-28kasan: fix hwasan build for gccArnd Bergmann1-6/+6
[ Upstream commit 5c595ac4c776c44b5c59de22ab43b3fe256d9fbb ] gcc-11 adds support for -fsanitize=kernel-hwaddress, so it becomes possible to enable CONFIG_KASAN_SW_TAGS. Unfortunately this fails to build at the moment, because the corresponding command line arguments use llvm specific syntax. Change it to use the cc-param macro instead, which works on both clang and gcc. [elver@google.com: fixup for "kasan: fix hwasan build for gcc"] Link: https://lkml.kernel.org/r/YHQZVfVVLE/LDK2v@elver.google.com Link: https://lkml.kernel.org/r/20210323124112.1229772-1-arnd@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Marco Elver <elver@google.com> Reviewed-by: Marco Elver <elver@google.com> Acked-by: Andrey Konovalov <andreyknvl@gmail.com> Cc: Masahiro Yamada <masahiroy@kernel.org> Cc: Michal Marek <michal.lkml@markovi.net> Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com> Cc: Nathan Chancellor <nathan@kernel.org> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Alexander Potapenko <glider@google.com> Cc: Dmitry Vyukov <dvyukov@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2024-10-14 00:21:20 +0300