From: Nathan Chancellor <nathan@kernel.org>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Kees Cook <kees@kernel.org>, Ard Biesheuvel <ardb+git@google.com>,
x86@kernel.org, llvm@lists.linux.dev,
linux-hardening@vger.kernel.org, stable@vger.kernel.org,
Fangrui Song <i@maskray.me>, Brian Gerst <brgerst@gmail.com>,
Uros Bizjak <ubizjak@gmail.com>,
Andy Lutomirski <luto@kernel.org>
Subject: Re: [PATCH v2] x86/stackprotector: Work around strict Clang TLS symbol requirements
Date: Tue, 15 Oct 2024 19:10:45 -0700 [thread overview]
Message-ID: <20241016021045.GA1000009@thelio-3990X> (raw)
In-Reply-To: <CAMj1kXF7aFyBOOxQQsvsAsnvo3FYrkU=KA1BiMeSuKq1KHC1qA@mail.gmail.com>
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
next prev parent reply other threads:[~2024-10-16 2:10 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-09 12:43 [PATCH v2] x86/stackprotector: Work around strict Clang TLS symbol requirements Ard Biesheuvel
2024-10-14 20:59 ` Kees Cook
2024-10-15 10:56 ` Ard Biesheuvel
2024-10-16 2:10 ` Nathan Chancellor [this message]
2024-10-16 6:48 ` Ard Biesheuvel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241016021045.GA1000009@thelio-3990X \
--to=nathan@kernel.org \
--cc=ardb+git@google.com \
--cc=ardb@kernel.org \
--cc=brgerst@gmail.com \
--cc=i@maskray.me \
--cc=kees@kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=luto@kernel.org \
--cc=stable@vger.kernel.org \
--cc=ubizjak@gmail.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).