kernel.git/arch/arm/boot/compressed/Makefile, branch linux-5.4.y

ARM: 9105/1: atags_to_fdt: don't warn about stack size

2021-09-22T10:26:22Z

commit b30d0289de72c62516df03fdad8d53f552c69839 upstream. The merge_fdt_bootargs() function by definition consumes more than 1024 bytes of stack because it has a 1024 byte command line on the stack, meaning that we always get a warning when building this file: arch/arm/boot/compressed/atags_to_fdt.c: In function 'merge_fdt_bootargs': arch/arm/boot/compressed/atags_to_fdt.c:98:1: warning: the frame size of 1032 bytes is larger than 1024 bytes [-Wframe-larger-than=] However, as this is the decompressor and we know that it has a very shallow call chain, and we do not actually risk overflowing the kernel stack at runtime here. This just shuts up the warning by disabling the warning flag for this file. Tested on Nexus 7 2012 builds. Acked-by: Nicolas Pitre Signed-off-by: David Heidelberg Signed-off-by: Arnd Bergmann Cc: Signed-off-by: Russell King (Oracle) Signed-off-by: Greg Kroah-Hartman

ARM: 9056/1: decompressor: fix BSS size calculation for LLVM ld.lld

2021-05-11T12:04:01Z

commit c4e792d1acce31c2eb7b9193ab06ab94de05bf42 upstream. The LLVM ld.lld linker uses a different symbol type for __bss_start, resulting in the calculation of KBSS_SZ to be thrown off. Up until now, this has gone unnoticed as it only affects the appended DTB case, but pending changes for ARM in the way the decompressed kernel is cleaned from the caches has uncovered this problem. On a ld.lld build: $ nm vmlinux |grep bss_ c1c22034 D __bss_start c1c86e98 B __bss_stop resulting in $ readelf -s arch/arm/boot/compressed/vmlinux | grep bss_size 433: c1c86e98 0 NOTYPE GLOBAL DEFAULT ABS _kernel_bss_size which is obviously incorrect, and may cause the cache clean to access unmapped memory, or cause the size calculation to wrap, resulting in no cache clean to be performed at all. Fix this by updating the sed regex to take D type symbols into account. Link: https://lore.kernel.org/linux-arm-kernel/6c65bcef-d4e7-25fa-43cf-2c435bb61bb9@collabora.com/ Link: https://lore.kernel.org/linux-arm-kernel/20210205085220.31232-1-ardb@kernel.org/ Cc: # v4.19+ Reviewed-by: Nick Desaulniers Tested-by: Nick Desaulniers Reported-by: Guillaume Tucker Reported-by: "kernelci.org bot" Signed-off-by: Ard Biesheuvel Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman

ARM: 8939/1: kbuild: use correct nm executable

2020-10-17T08:11:22Z

[ Upstream commit 29c623d64f0dcd6aa10e0eabd16233e77114090b ] Since $(NM) variable can be easily overridden for the whole build, it's better to use it instead of $(CROSS_COMPILE)nm. The use of $(CROSS_COMPILE) prefixed variables where their calculated equivalents can be used is incorrect. This fixes issues with builds where $(NM) is set to llvm-nm. Link: https://github.com/ClangBuiltLinux/linux/issues/766 Signed-off-by: Dmitry Golovin Suggested-by: Nick Desaulniers Cc: Matthias Maennich Reviewed-by: Nathan Chancellor Tested-by: Nathan Chancellor Reviewed-by: Masahiro Yamada Reviewed-by: Nick Desaulniers Signed-off-by: Russell King Signed-off-by: Sasha Levin

ARM: 8961/2: Fix Kbuild issue caused by per-task stack protector GCC plugin

2020-03-21T07:11:59Z

commit 89604523a76eb3e13014b2bdab7f8870becee284 upstream. When using plugins, GCC requires that the -fplugin= options precedes any of its plugin arguments appearing on the command line as well. This is usually not a concern, but as it turns out, this requirement is causing some issues with ARM's per-task stack protector plugin and Kbuild's implementation of $(cc-option). When the per-task stack protector plugin is enabled, and we tweak the implementation of cc-option not to pipe the stderr output of GCC to /dev/null, the following output is generated when GCC is executed in the context of cc-option: cc1: error: plugin arm_ssp_per_task_plugin should be specified before \ -fplugin-arg-arm_ssp_per_task_plugin-tso=1 in the command line cc1: error: plugin arm_ssp_per_task_plugin should be specified before \ -fplugin-arg-arm_ssp_per_task_plugin-offset=24 in the command line These errors will cause any option passed to cc-option to be treated as unsupported, which is obviously incorrect. The cause of this issue is the fact that the -fplugin= argument is added to GCC_PLUGINS_CFLAGS, whereas the arguments above are added to KBUILD_CFLAGS, and the contents of the former get filtered out of the latter before being passed to the GCC running the cc-option test, and so the -fplugin= option does not appear at all on the GCC command line. Adding the arguments to GCC_PLUGINS_CFLAGS instead of KBUILD_CFLAGS would be the correct approach here, if it weren't for the fact that we are using $(eval) to defer the moment that they are added until after asm-offsets.h is generated, which is after the point where the contents of GCC_PLUGINS_CFLAGS are added to KBUILD_CFLAGS. So instead, we have to add our plugin arguments to both. For similar reasons, we cannot append DISABLE_ARM_SSP_PER_TASK_PLUGIN to KBUILD_CFLAGS, as it will be passed to GCC when executing in the context of cc-option, whereas the other plugin arguments will have been filtered out, resulting in a similar error and false negative result as above. So add it to ccflags-y instead. Fixes: 189af4657186da08 ("ARM: smp: add support for per-task stack canaries") Reported-by: Merlijn Wajer Tested-by: Tony Lindgren Acked-by: Kees Cook Reviewed-by: Masahiro Yamada Signed-off-by: Ard Biesheuvel Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman

ARM: 8819/1: Remove '-p' from LDFLAGS

2019-02-01T21:44:07Z

This option is not supported by lld: ld.lld: error: unknown argument: -p This has been a no-op in binutils since 2004 (see commit dea514f51da1 in that tree). Given that the lowest officially supported of binutils for the kernel is 2.20, which was released in 2009, nobody needs this flag around so just remove it. Commit 1a381d4a0a9a ("arm64: remove no-op -p linker flag") did the same for arm64. Signed-off-by: Nathan Chancellor Acked-by: Ard Biesheuvel Acked-by: Nicolas Pitre Reviewed-by: Nick Desaulniers Reviewed-by: Stefan Agner Signed-off-by: Russell King

kbuild: remove redundant target cleaning on failure

2019-01-06T00:46:51Z

Since commit 9c2af1c7377a ("kbuild: add .DELETE_ON_ERROR special target"), the target file is automatically deleted on failure. The boilerplate code ... || { rm -f $@; false; } is unneeded. Signed-off-by: Masahiro Yamada

ARM: smp: add support for per-task stack canaries

2018-12-12T21:20:07Z

On ARM, we currently only change the value of the stack canary when switching tasks if the kernel was built for UP. On SMP kernels, this is impossible since the stack canary value is obtained via a global symbol reference, which means a) all running tasks on all CPUs must use the same value b) we can only modify the value when no kernel stack frames are live on any CPU, which is effectively never. So instead, use a GCC plugin to add a RTL pass that replaces each reference to the address of the __stack_chk_guard symbol with an expression that produces the address of the 'stack_canary' field that is added to struct thread_info. This way, each task will use its own randomized value. Cc: Russell King Cc: Kees Cook Cc: Emese Revfy Cc: Arnd Bergmann Cc: Laura Abbott Cc: kernel-hardening@lists.openwall.com Acked-by: Nicolas Pitre Signed-off-by: Ard Biesheuvel Signed-off-by: Kees Cook

arm: port KCOV to arm

2018-06-14T22:55:24Z

KCOV is code coverage collection facility used, in particular, by syzkaller system call fuzzer. There is some interest in using syzkaller on arm devices. So port KCOV to arm. On implementation level this merely declares that KCOV is supported and disables instrumentation of 3 special cases. Reasons for disabling are commented in code. Tested with qemu-system-arm/vexpress-a15. Link: http://lkml.kernel.org/r/20180511143248.112484-1-dvyukov@google.com Signed-off-by: Dmitry Vyukov Acked-by: Mark Rutland Cc: Russell King Cc: Abbott Liu Cc: Catalin Marinas Cc: Koguchi Takuo Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Merge branches 'fixes', 'misc' and 'spectre' into for-linus

2018-06-05T09:03:27Z

ARM: 8767/1: add support for building ARM kernel with clang

2018-05-19T10:53:46Z

Use cc-options call for compiler options which are not available in clang. With this patch an ARMv7 multi platform kernel can be successfully build using clang (tested with version 5.0.1). Based-on-patches-by: Behan Webster Signed-off-by: Stefan Agner Signed-off-by: Russell King