linux-kernel - Re: [PATCH 00/46] gcc-LTO support for the kernel

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]
Date:   Thu, 17 Nov 2022 16:15:33 +0100
From:   Ard Biesheuvel <ardb@...nel.org>
To:     Richard Biener <rguenther@...e.de>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        "Jiri Slaby (SUSE)" <jirislaby@...nel.org>,
        linux-kernel@...r.kernel.org,
        Alexander Potapenko <glider@...gle.com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Alexei Starovoitov <ast@...nel.org>,
        Alexey Makhalov <amakhalov@...are.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Andrey Konovalov <andreyknvl@...il.com>,
        Andrey Ryabinin <ryabinin.a.a@...il.com>,
        Andrii Nakryiko <andrii@...nel.org>,
        Andy Lutomirski <luto@...nel.org>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Ben Segall <bsegall@...gle.com>,
        Borislav Petkov <bp@...en8.de>,
        Daniel Borkmann <daniel@...earbox.net>,
        Daniel Bristot de Oliveira <bristot@...hat.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Don Zickus <dzickus@...hat.com>, Hao Luo <haoluo@...gle.com>,
        "H . J . Lu" <hjl.tools@...il.com>,
        "H. Peter Anvin" <hpa@...or.com>, Huang Rui <ray.huang@....com>,
        Ingo Molnar <mingo@...hat.com>, Jan Hubicka <jh@...e.de>,
        Jason Baron <jbaron@...mai.com>,
        Jiri Kosina <jikos@...nel.org>, Jiri Olsa <jolsa@...nel.org>,
        Joe Lawrence <joe.lawrence@...hat.com>,
        John Fastabend <john.fastabend@...il.com>,
        Josh Poimboeuf <jpoimboe@...nel.org>,
        Juergen Gross <jgross@...e.com>,
        Juri Lelli <juri.lelli@...hat.com>,
        KP Singh <kpsingh@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Martin KaFai Lau <martin.lau@...ux.dev>,
        Martin Liska <mliska@...e.cz>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Mel Gorman <mgorman@...e.de>, Miguel Ojeda <ojeda@...nel.org>,
        Michal Marek <michal.lkml@...kovi.net>,
        Miroslav Benes <mbenes@...e.cz>,
        Namhyung Kim <namhyung@...nel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Oleksandr Tyshchenko <oleksandr_tyshchenko@...m.com>,
        Petr Mladek <pmladek@...e.com>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Sedat Dilek <sedat.dilek@...il.com>,
        Song Liu <song@...nel.org>,
        Stanislav Fomichev <sdf@...gle.com>,
        Stefano Stabellini <sstabellini@...nel.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Valentin Schneider <vschneid@...hat.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Vincenzo Frascino <vincenzo.frascino@....com>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        VMware PV-Drivers Reviewers <pv-drivers@...are.com>,
        Yonghong Song <yhs@...com>
Subject: Re: [PATCH 00/46] gcc-LTO support for the kernel

On Thu, 17 Nov 2022 at 14:55, Richard Biener <rguenther@...e.de> wrote:
>
> On Thu, 17 Nov 2022, Ard Biesheuvel wrote:
>
...
> > We have an __ADDRESSABLE() macro and asmlinkage modifier to annotate
> > symbols that may appear to the compiler as though they are never
> > referenced.
> >
> > Would it be possible to repurpose those so that the LTO code knows
> > which symbols it must not remove?
>
> I find
>
> /*
>  * Force the compiler to emit 'sym' as a symbol, so that we can reference
>  * it from inline assembler. Necessary in case 'sym' could be inlined
>  * otherwise, or eliminated entirely due to lack of references that are
>  * visible to the compiler.
>  */
> #define ___ADDRESSABLE(sym, __attrs) \
>         static void * __used __attrs \
>                 __UNIQUE_ID(__PASTE(__addressable_,sym)) = (void *)&sym;
> #define __ADDRESSABLE(sym) \
>         ___ADDRESSABLE(sym, __section(".discard.addressable"))
>
> that should be enough to force LTO keeping 'sym' - unless there's
> a linker script that discards .discard.addressable which I fear LTO
> will notice, losing the effect.  A more direct way would be to attach
> __used to 'sym' directly.  __ADDRESSABLE doesn't seem to be used
> directly but instead I see cases like
>
> #define __define_initcall_stub(__stub, fn)                      \
>         int __init __stub(void);                                \
>         int __init __stub(void)                                 \
>         {                                                       \
>                 return fn();                                    \
>         }                                                       \
>         __ADDRESSABLE(__stub)
>
> where one could have added __used to the __stub prototypes instead?
>

Probably, yes.

But my point was not really about the implementation of those things,
more about whether we could redefine them to something else that would
help the compiler infer that this symbol needs to be retained.

asmlinkage in particular seems relevant, which is currently only used
for C++ inclusion or for setting regparm{0} on i386.