On Tue, Oct 15, 2024 at 12:56:57PM +0200, Ard Biesheuvel wrote:
On Mon, 14 Oct 2024 at 22:59, Kees Cook kees@kernel.org wrote:
On Wed, Oct 09, 2024 at 02:43:53PM +0200, Ard Biesheuvel wrote:
However, if a non-TLS definition of the symbol in question is visible in the same compilation unit (which amounts to the whole of vmlinux if LTO is enabled), it will drop the per-CPU prefix and emit a load from a bogus address.
I take this to mean that x86 32-bit kernels built with the stack protector and using Clang LTO will crash very quickly?
Yeah. The linked issue is not quite clear, but it does suggest things are pretty broken in that case.
Yeah, i386_defconfig with CONFIG_LTO_CLANG_FULL=y explodes on boot for me without this change:
[ 0.000000] Linux version 6.12.0-rc3-00044-g2f87d0916ce0 (nathan@thelio-3990X) (ClangBuiltLinux clang version 19.1.2 (https://github.com/llvm/llvm-project.git 7ba7d8e2f7b6445b60679da826210cdde29eaf8b), ClangBuiltLinux LLD 19.1.2 (https://github.com/llvm/llvm-project.git 7ba7d8e2f7b6445b60679da826210cdde29eaf8b)) #1 SMP PREEMPT_DYNAMIC Tue Oct 15 19:00:21 MST 2024 ... [ 0.631002] Freeing unused kernel image (initmem) memory: 936K [ 0.631613] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: free_initmem+0x95/0x98 [ 0.632606] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc3-00044-g2f87d0916ce0 #1 [ 0.633467] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 0.634583] Call Trace: [ 0.634837] panic+0xd4/0x2cc [ 0.635146] ? _vdso_rng_data+0xd80/0xd80 [ 0.635550] ? _vdso_rng_data+0xd80/0xd80 [ 0.635965] ? rest_init+0xb0/0xb0 [ 0.636312] __stack_chk_fail+0x10/0x10 [ 0.636701] ? free_initmem+0x95/0x98 [ 0.637074] free_initmem+0x95/0x98 [ 0.637434] ? _vdso_rng_data+0xd80/0xd80 [ 0.637838] ? rest_init+0xb0/0xb0 [ 0.638196] kernel_init+0x42/0x1e4 [ 0.638558] ret_from_fork+0x2b/0x40 [ 0.638922] ret_from_fork_asm+0x12/0x18 [ 0.639331] entry_INT80_32+0x108/0x108 [ 0.639864] Kernel Offset: disabled [ 0.640224] ---[ end Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: free_initmem+0x95/0x98 ]---
I can confirm that this patch resolves that issue for me and LKDTM's REPORT_STACK_CANARY test passes with that configuration.
Reviewed-by: Nathan Chancellor nathan@kernel.org Tested-by: Nathan Chancellor nathan@kernel.org
I presume the '#ifndef CONFIG_X86_64' in arch/x86/entry/entry.S is present because only X86_32 uses '-mstack-protector-guard-reg='? I assume that will disappear when X86_64 supports this option (IIRC that was the plan)?
Cheers, Nathan