linux-kernel - Re: [PATCH v2] kbuild: Fail if gold linker is detected

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: <20190716233708.GA11824@mit.edu>
Date:   Tue, 16 Jul 2019 19:37:08 -0400
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Mike Lothian <mike@...eburn.co.uk>,
        Nathan Chancellor <natechancellor@...il.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>, x86@...nel.org,
        "H.J. Lu" <hjl.tools@...il.com>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        linux-kbuild@...r.kernel.org
Subject: Re: [PATCH v2] kbuild: Fail if gold linker is detected

On Wed, Jul 17, 2019 at 12:25:14AM +0200, Thomas Gleixner wrote:
> > It's been my default system linker for years and I've had very few issues
> > with it and it's a big improvement when linking with LTO
> 
> I understand, but the fact that you need to turn off config options in
> order to build a kernel and the clear statement that it's not recommended
> makes it truly unsuitable and unmaintainable for us.

Or if you work for a cloud company who is willing to make the gold
linker work for your specific use case and configuration (and ideally,
have gold toolchain experts on staff who will work with you), then it
might be OK, but just for that particular use case.  (Just as Android
kernels worked with Clang when Clang was still miscompiling kernel on
different architectures and configurations.)  In those cases, you can
just carry a patch to force the gold linker to work.

The point though is the teams that were using alternative,
not-always-reliable toolchains, were big boys and girls, and they
weren't asking the upstream kernel devs for support.  And they only
cared about a few specific configurations, and not something that
would work for all or even most configurations and hardware platforms.

	      	       	      	   	- Ted