| 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
| ||
|
Message-ID: <CAF1bQ=QgBBEBt1sZYM0HfGf_NhC+cX73Vf+wcu7dSsZ639EGXQ@mail.gmail.com> Date: Mon, 29 Jul 2024 13:55: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>, 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 3/6] Change the symbols order when --ffuntion-sections is enabled On Mon, Jul 29, 2024 at 2:34 AM Peter Zijlstra <peterz@...radead.org> wrote: > > On Sun, Jul 28, 2024 at 01:29:56PM -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. > > > > 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> > > --- > > include/asm-generic/vmlinux.lds.h | 19 ++++++++++++++++--- > > 1 file changed, 16 insertions(+), 3 deletions(-) > > > > diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h > > index 5703526d6ebf..f3de66bda293 100644 > > --- a/include/asm-generic/vmlinux.lds.h > > +++ b/include/asm-generic/vmlinux.lds.h > > @@ -582,9 +582,21 @@ > > * during second ld run in second ld pass when generating System.map > > * > > * 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. > > + * code elimination or function-section is enabled. Match these symbols > > + * first when in these builds. > > */ > > +#if defined(CONFIG_LD_DEAD_CODE_DATA_ELIMINATION) || defined(CONFIG_LTO_CLANG) > > +#define TEXT_TEXT \ > > + *(.text.asan.* .text.tsan.*) \ > > + *(.text.unknown .text.unknown.*) \ > > + *(.text.unlikely .text.unlikely.*) \ > > + ALIGN_FUNCTION(); \ > > Why leave the above text sections unaligned? They are considered cold text. They are not aligned before the change. But I have no objections to making it aligned. (Sorry if you receive a duplicated message. I'm resending this in plain text mode.) > > > + *(.text.hot .text.hot.*) \ > > + *(TEXT_MAIN .text.fixup) \ > > + NOINSTR_TEXT \ > > + *(.ref.text) \ > > + MEM_KEEP(init.text*) > > +#else > > #define TEXT_TEXT \ > > ALIGN_FUNCTION(); \ > > *(.text.hot .text.hot.*) \ > > @@ -594,7 +606,8 @@ > > NOINSTR_TEXT \ > > *(.ref.text) \ > > *(.text.asan.* .text.tsan.*) \ > > - MEM_KEEP(init.text*) \ > > + MEM_KEEP(init.text*) > > +#endif > > > > > > /* sched.text is aling to function alignment to secure we have same > > -- > > 2.46.0.rc1.232.g9752f9e123-goog > >
Powered by blists - more mailing lists