linux-kernel - Re: [PATCH 2/6] objtool: Fix unreachable instruction warnings for weak funcitons

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: <20240729092840.GB37996@noisy.programming.kicks-ass.net>
Date: Mon, 29 Jul 2024 11:28:40 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Rong Xu <xur@...gle.com>
Cc: Han Shen <shenhan@...gle.com>, Sriraman Tallam <tmsriram@...gle.com>,
	David Li <davidxl@...gle.com>, Jonathan Corbet <corbet@....net>,
	Masahiro Yamada <masahiroy@...nel.org>,
	Nathan Chancellor <nathan@...nel.org>,
	Nicolas Schier <nicolas@...sle.eu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
	Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
	"H . Peter Anvin" <hpa@...or.com>, Ard Biesheuvel <ardb@...nel.org>,
	Arnd Bergmann <arnd@...db.de>, Josh Poimboeuf <jpoimboe@...nel.org>,
	Nick Desaulniers <ndesaulniers@...gle.com>,
	Bill Wendling <morbo@...gle.com>,
	Justin Stitt <justinstitt@...gle.com>,
	Vegard Nossum <vegard.nossum@...cle.com>,
	John Moon <john@...on.dev>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Heiko Carstens <hca@...ux.ibm.com>,
	Luis Chamberlain <mcgrof@...nel.org>,
	Samuel Holland <samuel.holland@...ive.com>,
	Mike Rapoport <rppt@...nel.org>,
	"Paul E . McKenney" <paulmck@...nel.org>,
	Rafael Aquini <aquini@...hat.com>, Petr Pavlu <petr.pavlu@...e.com>,
	Eric DeVolder <eric.devolder@...cle.com>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Randy Dunlap <rdunlap@...radead.org>,
	Benjamin Segall <bsegall@...gle.com>,
	Breno Leitao <leitao@...ian.org>,
	Wei Yang <richard.weiyang@...il.com>,
	Brian Gerst <brgerst@...il.com>, Juergen Gross <jgross@...e.com>,
	Palmer Dabbelt <palmer@...osinc.com>,
	Alexandre Ghiti <alexghiti@...osinc.com>,
	Kees Cook <kees@...nel.org>,
	Sami Tolvanen <samitolvanen@...gle.com>,
	Xiao Wang <xiao.w.wang@...el.com>,
	Jan Kiszka <jan.kiszka@...mens.com>, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-kbuild@...r.kernel.org,
	linux-efi@...r.kernel.org, linux-arch@...r.kernel.org,
	llvm@...ts.linux.dev, Krzysztof Pszeniczny <kpszeniczny@...gle.com>
Subject: Re: [PATCH 2/6] objtool: Fix unreachable instruction warnings for
 weak funcitons

On Sun, Jul 28, 2024 at 01:29:55PM -0700, Rong Xu wrote:
> In the presence of both weak and strong function definitions, the
> linker drops the weak symbol in favor of a strong symbol, but
> leaves the code in place. Code in ignore_unreachable_insn() has
> some heuristics to suppress the warning, but it does not work when
> -ffunction-sections is enabled.
> 
> Suppose function foo has both strong and weak definitions.
> Case 1: The strong definition has an annotated section name,
> like .init.text. Only the weak definition will be placed into
> .text.foo. But since the section has no symbols, there will be no
> "hole" in the section.
> 
> Case 2: Both sections are without an annotated section name.
> Both will be placed into .text.foo section, but there will be only one
> symbol (the strong one). If the weak code is before the strong code,
> there is no "hole" as it fails to find the right-most symbol before
> the offset.
> 
> The fix is to use the first node to compute the hole if hole.sym
> is empty. If there is no symbol in the section, the first node
> will be NULL, in which case, -1 is returned to skip the whole
> section.
> 
> Co-developed-by: Han Shen <shenhan@...gle.com>
> Signed-off-by: Han Shen <shenhan@...gle.com>
> Signed-off-by: Rong Xu <xur@...gle.com>
> Suggested-by: Sriraman Tallam <tmsriram@...gle.com>
> Suggested-by: Krzysztof Pszeniczny <kpszeniczny@...gle.com>
> ---
>  tools/objtool/elf.c | 13 ++++++++-----
>  1 file changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c
> index 3d27983dc908..fa88bb254ccc 100644
> --- a/tools/objtool/elf.c
> +++ b/tools/objtool/elf.c
> @@ -224,12 +224,15 @@ int find_symbol_hole_containing(const struct section *sec, unsigned long offset)
>  	if (n)
>  		return 0; /* not a hole */
>  
> -	/* didn't find a symbol for which @offset is after it */
> -	if (!hole.sym)
> -		return 0; /* not a hole */
> +	/*
> +	 * @offset >= sym->offset + sym->len, find symbol after it.
> +	 * Use the first node in rb_tree when hole.sym is NULL.
> +	 */

	/*
	 * If we are not right of any symbol, the next symbol must be
	 * the first symbol. Either way, the next symbol -- if there is
	 * one -- provides the rightmost boundary of the hole.
	 */
	if (!hole.sym)
		n = rb_first_cached(&sec->symbol_tree);
	else
		n = rb_next(&hole.sym->node);


That tells us more of why, rather than of what. Hmm?

> +	if (hole.sym)
> +		n = rb_next(&hole.sym->node);
> +	else
> +		n = rb_first_cached(&sec->symbol_tree);
>  
> -	/* @offset >= sym->offset + sym->len, find symbol after it */
> -	n = rb_next(&hole.sym->node);
>  	if (!n)
>  		return -1; /* until end of address space */
>  
> -- 
> 2.46.0.rc1.232.g9752f9e123-goog
>