linux-kernel - Re: [PATCH] x86/stackprotector: fix build failure with CONFIG

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: <CAMj1kXF8PZq4660mzNYcT=QmWywB1gOOfZGzZhi1sQxQacUX=g@mail.gmail.com>
Date: Fri, 6 Dec 2024 16:17:49 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: Brian Gerst <brgerst@...il.com>
Cc: Oleg Nesterov <oleg@...hat.com>, linux-kernel@...r.kernel.org, x86@...nel.org, 
	Ingo Molnar <mingo@...nel.org>, "H . Peter Anvin" <hpa@...or.com>, Thomas Gleixner <tglx@...utronix.de>, 
	Borislav Petkov <bp@...en8.de>, Uros Bizjak <ubizjak@...il.com>, stable@...r.kernel.org, 
	Fangrui Song <i@...kray.me>, Nathan Chancellor <nathan@...nel.org>, Andy Lutomirski <luto@...nel.org>
Subject: Re: [PATCH] x86/stackprotector: fix build failure with CONFIG_STACKPROTECTOR=n

On Fri, 6 Dec 2024 at 16:12, Brian Gerst <brgerst@...il.com> wrote:
>
> On Fri, Dec 6, 2024 at 9:37 AM Ard Biesheuvel <ardb@...nel.org> wrote:
> >
> > On Fri, 6 Dec 2024 at 15:22, Oleg Nesterov <oleg@...hat.com> wrote:
> > >
> > > On 12/06, Ard Biesheuvel wrote:
> > > >
> > > > On Fri, 6 Dec 2024 at 13:32, Oleg Nesterov <oleg@...hat.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 2
> > >
> > > perhaps this is because my toolchain is quite old,
> > >
> > >         $ ld -v
> > >         GNU ld version 2.25-17.fc23
> > >
> > > but according to Documentation/process/changes.rst
> > >
> > >         binutils               2.25             ld -v
> > >
> > > it 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@...nel.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.