On Fri, 6 Dec 2024 at 16:12, Brian Gerst brgerst@gmail.com wrote:
On Fri, Dec 6, 2024 at 9:37 AM Ard Biesheuvel ardb@kernel.org wrote:
On Fri, 6 Dec 2024 at 15:22, Oleg Nesterov oleg@redhat.com wrote:
On 12/06, Ard Biesheuvel wrote:
On Fri, 6 Dec 2024 at 13:32, Oleg Nesterov oleg@redhat.com wrote:
+#ifdef CONFIG_STACKPROTECTOR /* needed for Clang - see arch/x86/entry/entry.S */ PROVIDE(__ref_stack_chk_guard = __stack_chk_guard); +#endif
#ifdef CONFIG_X86_64 /*
This shouldn't be necessary - PROVIDE() is only evaluated if a reference exists to the symbol it defines.
Also, I'm failing to reproduce this. Could you share your .config, please, and the error that you get during the build?
Please see the attached .config
without the change above:
$ make bzImage CALL scripts/checksyscalls.sh DESCEND objtool INSTALL libsubcmd_headers UPD include/generated/utsversion.h CC init/version-timestamp.o KSYMS .tmp_vmlinux0.kallsyms.S AS .tmp_vmlinux0.kallsyms.o LD .tmp_vmlinux1 ./arch/x86/kernel/vmlinux.lds:154: undefined symbol `__stack_chk_guard' referenced in expression scripts/Makefile.vmlinux:77: recipe for target 'vmlinux' failed make[2]: *** [vmlinux] Error 1 /home/oleg/tmp/LINUX/Makefile:1225: recipe for target 'vmlinux' failed make[1]: *** [vmlinux] Error 2 Makefile:251: recipe for target '__sub-make' failed make: *** [__sub-make] Error 2perhaps this is because my toolchain is quite old,
$ ld -v GNU ld version 2.25-17.fc23but according to Documentation/process/changes.rst
binutils 2.25 ld -vit is still supported.
We're about to bump the minimum toolchain requirements to GCC 8.1 (and whichever version of binutils was current at the time), so you might want to consider upgrading.
However, you are right that these are still supported today, and so we need this fix this, especially because this has been backported to older stable kernels too.
For the patch,
Acked-by: Ard Biesheuvel ardb@kernel.org
Using PROVIDES() is now unnecessary.
At this point, the use of -mstack-protector-guard-symbol is still limited to 32-bit x86. However, if we drop PROVIDE() here, the 64-bit kernel will also gain a symbol `__ref_stack_chk_guard` in its symbol table (and /proc/kallsyms, most likely).
Not sure whether that matters or not, but I'd rather keep the PROVIDE() as it doesn't do any harm.