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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAF1bQ=TTfjh1UukJNZ2bbovagXFmS3i78=ALwDt+qfVe3wr7Vg@mail.gmail.com>
Date: Thu, 3 Oct 2024 11:12:10 -0700
From: Rong Xu <xur@...gle.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Han Shen <shenhan@...gle.com>, Sriraman Tallam <tmsriram@...gle.com>, 
	David Li <davidxl@...gle.com>, Krzysztof Pszeniczny <kpszeniczny@...gle.com>, 
	Alice Ryhl <aliceryhl@...gle.com>, Andrew Morton <akpm@...ux-foundation.org>, 
	Arnd Bergmann <arnd@...db.de>, Bill Wendling <morbo@...gle.com>, Borislav Petkov <bp@...en8.de>, 
	Breno Leitao <leitao@...ian.org>, Brian Gerst <brgerst@...il.com>, 
	Dave Hansen <dave.hansen@...ux.intel.com>, Heiko Carstens <hca@...ux.ibm.com>, 
	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>, Jann Horn <jannh@...gle.com>, 
	Jonathan Corbet <corbet@....net>, Josh Poimboeuf <jpoimboe@...nel.org>, Juergen Gross <jgross@...e.com>, 
	Justin Stitt <justinstitt@...gle.com>, Kees Cook <kees@...nel.org>, linux-arch@...r.kernel.org, 
	linux-doc@...r.kernel.org, linux-kbuild@...r.kernel.org, 
	linux-kernel@...r.kernel.org, llvm@...ts.linux.dev, 
	Masahiro Yamada <masahiroy@...nel.org>, "Mike Rapoport (IBM)" <rppt@...nel.org>, 
	Nathan Chancellor <nathan@...nel.org>, Nick Desaulniers <ndesaulniers@...gle.com>, 
	Nicolas Schier <nicolas@...sle.eu>, "Paul E. McKenney" <paulmck@...nel.org>, 
	Samuel Holland <samuel.holland@...ive.com>, Thomas Gleixner <tglx@...utronix.de>, 
	Wei Yang <richard.weiyang@...il.com>, workflows@...r.kernel.org, x86@...nel.org, 
	"Xin Li (Intel)" <xin@...or.com>
Subject: Re: [PATCH v2 3/6] Change the symbols order when --ffuntion-sections
 is enabled

In principle, I don't see a problem using the new order unconditionally.

This new ordering of sections (.text.unlikely, .text.hot, then .text)
differs from the typical user-space ordering when no link-script is
used. Usually, the order is .text, .text.hot, and then .text.unlikely
(when -z keep-text-section-prefix is used).

However, for normal kernel builds that don't use FDO (iFDO and
AutoFDO), this change has minimal impact. This is because the
.text.unlikely section is very small, containing only functions
specifically annotated as cold by the user.

When using FDO, either with iFDO or AutoFDO, this new section ordering
(.text.unlikely, .text.hot, then .text) should be used. These builds
should enable -ffunction-sections and use the new order for
function-level grouping.

This new ordering also affects the placement of ASan and TSan code.
While I expect that this change won't cause issues for them, sanitizer
developers should confirm this.

We've tested this new ordering with iFDO (PGO), AutoFDO, and standard
non-FDO builds. But I think more extensive testing is needed before
using it unconditionally.

-Rong

On Thu, Oct 3, 2024 at 8:43 AM Peter Zijlstra <peterz@...radead.org> wrote:
>
> On Wed, Oct 02, 2024 at 04:34:02PM -0700, Rong Xu wrote:
> > When the -ffunction-sections compiler option is enabled, each function
> > is placed in a separate section named .text.function_name rather than
> > putting all functions in a single .text section.
> >
> > However, using -function-sections can cause problems with the
> > linker script. The comments included in include/asm-generic/vmlinux.lds.h
> > note these issues.:
> >   “TEXT_MAIN here will match .text.fixup and .text.unlikely if dead
> >    code elimination is enabled, so these sections should be converted
> >    to use ".." first.”
> >
> > It is unclear whether there is a straightforward method for converting
> > a suffix to "..". This patch modifies the order of subsections within the
> > text output section when the -ffunction-sections flag is enabled.
> > Specifically, it repositions sections with certain fixed patterns (for
> > example .text.unlikely) before TEXT_MAIN, ensuring that they are grouped
> > and matched together.
> >
> > Note that the limitation arises because the linker script employs glob
> > patterns instead of regular expressions for string matching. While there
> > is a method to maintain the current order using complex patterns, this
> > significantly complicates the pattern and increases the likelihood of
> > errors.
>
> Is there a down-side to using the new order unconditionally?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ