On Fri, 26 Feb 2021, Masahiro Yamada wrote: > On Fri, Feb 26, 2021 at 2:20 AM Nicolas Pitre <nico@xxxxxxxxxxx> wrote: > > > > 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. > > Linus is not using this feature, but does build tests. > After pulling the module subsystem pull request in this merge window, > CONFIG_TRIM_UNUSED_KSYMS was enabled by allmodconfig. If CONFIG_TRIM_UNUSED_KSYMS is enabled then build time willincrease. That comes with the feature. > > 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. > > > Clang LTO landed in this MW. > > Do you think it will reduce the kernel binary size? > No, opposite. LTO ought to reduce binary size. It is rather broken otherwise. Having a global view before optimizing allows for the compiler to do project wide constant propagation and dead code elimination. > CONFIG_LTO_CLANG cannot trim any code even if it > is obviously unused. > Hence, it never reduces the kernel binary size. > Rather, it produces a bigger kernel. Then what's the point? > The reason is Clang LTO was implemented against > relocatable ELF (vmlinux.o) . That's not true LTO then. > I pointed out this flaw in the review process, but > it was dismissed. > > This is the main reason why I did not give any Ack > (but it was merged via Kees Cook's tree). > So, the help text of this option should be revised: > > This option allows for unused exported symbols to be dropped from > the build. In turn, this provides the compiler more opportunities > (especially when using LTO) for optimizing the code and reducing > binary size. This might have some security advantages as well. > > Clang LTO is opposite to your expectation. Then Clang LTO is a misnomer. That is the option to revise not this one. > > 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. > > I do not understand. > > Modules are relocatable ELF. > Clang LTO cannot eliminate any code. > GCC LTO does not work with relocatable ELF > in the first place. I don't think I follow you here. What relocatable ELF has to do with LTO? I've successfully used gcc LTO on the kernel quite a while ago. For a reference about binary size reduction with LTO and CONFIG_TRIM_UNUSED_KSYMS please read this article: https://lwn.net/Articles/746780/ Nicolas
