linux-kernel - Re: [PATCH v2 0/7] linkage: better symbol aliasing

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: <YfAbMY6U4UpyrerB@FVFF77S0Q05N>
Date:   Tue, 25 Jan 2022 15:45:53 +0000
From:   Mark Rutland <mark.rutland@....com>
To:     Ard Biesheuvel <ardb@...nel.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        acme@...hat.com, Borislav Petkov <bp@...en8.de>,
        Mark Brown <broonie@...nel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Jiri Slaby <jslaby@...e.cz>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Russell King <linux@...linux.org.uk>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Will Deacon <will@...nel.org>
Subject: Re: [PATCH v2 0/7] linkage: better symbol aliasing

On Tue, Jan 25, 2022 at 04:28:11PM +0100, Ard Biesheuvel wrote:
> On Tue, 25 Jan 2022 at 12:32, Mark Rutland <mark.rutland@....com> wrote:
> >
> > This series aims to make symbol aliasing simpler and more consistent.
> > The basic idea is to replace SYM_FUNC_START_ALIAS(alias) and
> > SYM_FUNC_END_ALIAS(alias) with a new SYM_FUNC_ALIAS(alias, name), so
> > that e.g.
> >
> >     SYM_FUNC_START(func)
> >     SYM_FUNC_START_ALIAS(alias1)
> >     SYM_FUNC_START_ALIAS(alias2)
> >         ... asm insns ...
> >     SYM_FUNC_END(func)
> >     SYM_FUNC_END_ALIAS(alias1)
> >     SYM_FUNC_END_ALIAS(alias2)
> >     EXPORT_SYMBOL(alias1)
> >     EXPORT_SYMBOL(alias2)
> >
> > ... can become:
> >
> >     SYM_FUNC_START(name)
> >         ... asm insns ...
> >     SYM_FUNC_END(name)
> >
> >     SYM_FUNC_ALIAS(alias1, func)
> >     EXPORT_SYMBOL(alias1)
> >
> >     SYM_FUNC_ALIAS(alias2, func)
> >     EXPORT_SYMBOL(alias2)
> >
> > This avoids repetition and hopefully make it easier to ensure
> > consistency (e.g. so each function has a single canonical name and
> > associated metadata).
> >
> 
> I take it this affects the sizes of the alias ELF symbols? Does that matter?

The alias should be given the same size as the original symbol, unless I've
made an error. If you look at patch 3:

* In SYM_FUNC_START(name), via SYM_ENTRY_AT(name, ...), we create a local label
  for the start of the function: .L____sym_entry__##name

* In SYM_FUNC_END(name), via SYM_END_AT(name, ...), we create a local label for
  the end of the function: .L____sym_end__##name

* In SYM_FUNC_ALIAS*(alias,name), we define the start and end of the alias as
  the start and end of the original symbol using those local labels, e.g.

  | #define SYM_FUNC_ALIAS(alias, name)                                     \
  |         SYM_START_AT(alias, .L____sym_entry__##name, SYM_L_GLOBAL)      \
  |         SYM_END_AT(alias, .L____sym_end__##name, SYM_T_FUNC)

Note that:

* SYM_FUNC_START() uses SYM_START(), which uses SYM_ENTRY_AT()
* SYM_FUNC_END() uses SYM_END(), which uses SYM_END_AT()

... so the definition of tha alias is ultimately structurally identical to the
definition of the canoncial name, at least for now.

Thanks,
Mark.