linux-kernel - Re: [PATCH] serial: icom: Fix namespace collision and startup() section placement with -ffunction-sections

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251119084315.GI4067720@noisy.programming.kicks-ass.net>
Date: Wed, 19 Nov 2025 09:43:15 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Jiri Slaby <jirislaby@...nel.org>
Cc: Josh Poimboeuf <jpoimboe@...nel.org>, x86@...nel.org,
	linux-kernel@...r.kernel.org,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	kernel test robot <lkp@...el.com>
Subject: Re: [PATCH] serial: icom: Fix namespace collision and startup()
 section placement with -ffunction-sections

On Wed, Nov 19, 2025 at 07:58:05AM +0100, Jiri Slaby wrote:
> On 19. 11. 25, 7:27, Josh Poimboeuf wrote:
> > When compiling the kernel with -ffunction-sections (e.g., for LTO,
> > livepatch, dead code elimination, AutoFDO, or Propeller), the startup()
> > function gets compiled into the .text.startup section.  In some cases it
> > can even be cloned into .text.startup.constprop.0 or
> > .text.startup.isra.0.
> > 
> > However, the .text.startup and .text.startup.* section names are already
> > reserved for use by the compiler for __attribute__((constructor)) code.
> > 
> > This naming conflict causes the vmlinux linker script to wrongly place
> > startup() function code in .init.text, which gets freed during boot.
> 
> This sounds rather error-prone. What are the patterns supposed to match
> actually? Can't *those* real victims™ be renamed to something less common
> instead?

Yeah, this is a terrible mess. The problem is that when linking objects
build with and without -ffunction-sections you can no longer uniquely
identify what's what :-(

As long as its consistently one or the other it works, but if you mix
them constructors and normal function like this get mixed up.

In another thread I've suggested this might be a toolchain bug, but even
if they agree and fix it, we still stuck with the old compilers. And I'm
not sure the toolchain people are agreeing there's anything wrong here
-- the argument is that you shouldn't be mixing this or somesuch.

Anyway, objtool has a warning for this, so new occurrences should be
flagged before they get introduced. But yes, we need to make the tree
clean first.