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: <r3584n3-sq21-qo49-9sp5-r3qp6o611s55@syhkavp.arg>
Date:   Thu, 25 Feb 2021 12:19:36 -0500 (EST)
From:   Nicolas Pitre <nico@...xnic.net>
To:     Masahiro Yamada <masahiroy@...nel.org>
cc:     linux-kbuild@...r.kernel.org, Christoph Hellwig <hch@....de>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Jessica Yu <jeyu@...nel.org>,
        Sami Tolvanen <samitolvanen@...gle.com>,
        linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org
Subject: Re: [PATCH 0/4] kbuild: build speed improvment of
 CONFIG_TRIM_UNUSED_KSYMS

On Fri, 26 Feb 2021, Masahiro Yamada wrote:

> 
> Now CONFIG_TRIM_UNUSED_KSYMS is revived, but Linus is still unhappy
> about the build speed.
> 
> I re-implemented this feature, and the build time cost is now
> almost unnoticeable level.
> 
> I hope this makes Linus happy.

:-)

I'm surprised to see that Linus is using this feature. When disabled 
(the default) this should have had no impact on the build time.

This feature provides a nice security advantage by significantly 
reducing the kernel input surface. And people are using that also to 
better what third party vendor can and cannot do with a distro kernel, 
etc. But that's not the reason why I implemented this feature in the 
first place.

My primary goal was to efficiently reduce the kernel binary size using 
LTO even with kernel modules enabled. Each EXPORT_SYMBOL() created a 
symbol dependency that prevented LTO from optimizing out the related 
code even though a tiny fraction of those exported symbols were needed.

The idea behind the recursion was to catch those cases where disabling 
an exported symbol within a module would optimize out references to more 
exported symbols that, in turn, could be disabled and possibly trigger 
yet more code elimination. There is no way that can be achieved without 
extra compiler passes in a recursive manner.


Nicolas

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ