linux-hardening - Re: [PATCH v2] x86/stackprotector: Work around strict Clang TLS symbol requirements

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAMj1kXEprSJpugRhVt7x2c1QfYxzFPHyBukpntPekT5N0ED-aA@mail.gmail.com>
Date: Wed, 16 Oct 2024 08:48:37 +0200
From: Ard Biesheuvel <ardb@...nel.org>
To: Nathan Chancellor <nathan@...nel.org>
Cc: Kees Cook <kees@...nel.org>, Ard Biesheuvel <ardb+git@...gle.com>, x86@...nel.org, 
	llvm@...ts.linux.dev, linux-hardening@...r.kernel.org, stable@...r.kernel.org, 
	Fangrui Song <i@...kray.me>, Brian Gerst <brgerst@...il.com>, Uros Bizjak <ubizjak@...il.com>, 
	Andy Lutomirski <luto@...nel.org>
Subject: Re: [PATCH v2] x86/stackprotector: Work around strict Clang TLS
 symbol requirements

On Wed, 16 Oct 2024 at 04:10, Nathan Chancellor <nathan@...nel.org> wrote:
>
> On Tue, Oct 15, 2024 at 12:56:57PM +0200, Ard Biesheuvel wrote:
> > On Mon, 14 Oct 2024 at 22:59, Kees Cook <kees@...nel.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@...lio-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@...nel.org>
> Tested-by: Nathan Chancellor <nathan@...nel.org>
>

Thanks.

> 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)?
>

Yes, I noticed this issue while enabling
'-mstack-protector-guard-reg=' for x86_64, but i386 is already broken.