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:   Mon, 14 Nov 2022 20:40:50 +0100
From:   Ard Biesheuvel <ardb@...nel.org>
To:     "Jiri Slaby (SUSE)" <jirislaby@...nel.org>
Cc:     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>,
        Peter Zijlstra <peterz@...radead.org>,
        Petr Mladek <pmladek@...e.com>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Richard Biener <RGuenther@...e.com>,
        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 Mon, 14 Nov 2022 at 12:44, Jiri Slaby (SUSE) <jirislaby@...nel.org> wrote:
>
> Hi,
>
> this is the first call for comments (and kbuild complaints) for this
> support of gcc (full) LTO in the kernel. Most of the patches come from
> Andi. Me and Martin rebased them to new kernels and fixed the to-use
> known issues. Also I updated most of the commit logs and reordered the
> patches to groups of patches with similar intent.
>
> The very first patch comes from Alexander and is pending on some x86
> queue already (I believe). I am attaching it only for completeness.
> Without that, the kernel does not boot (LTO reorders a lot).
>
> In our measurements, the performance differences are negligible.
>
> The kernel is bigger with gcc LTO due to more inlining.

OK, so if I understand this correctly:
- the performance is the same
- the resulting image is bigger
- we need a whole lot of ugly hacks to placate the linker.

Pardon my cynicism, but this cover letter does not mention any
advantages of LTO, so what is the point of all of this?

(On Clang, LTO was needed for CFI, but this is not even the case anymore)