| Message ID | 20171115213428.22559-11-samitolvanen@google.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, Nov 15, 2017 at 01:34:20PM -0800, Sami Tolvanen wrote: > CONFIG_CLANG_LTO depends on GNU gold and due to a known bug, the > linker crashes when ARM64_MODULE_PLTS is enabled: > > https://sourceware.org/bugzilla/show_bug.cgi?id=14592 > > To work around the problem, this change removes NOLOAD from .plt > and .init.plt, which allows us to link modules with ld.gold. Why don't we just not do LTO if the toolchain is busted? This feels like it will end up being a game of whack-a-mole as code could be introduced that tickles known bugs on older toolchains. Will
On Thu, Nov 16, 2017 at 11:50:12AM +0000, Will Deacon wrote: > Why don't we just not do LTO if the toolchain is busted? Because LTO can not only potentially improve performance, especially when combined with PGO (Profile Guided Optimization), but it also makes it possible to enable features like Control Flow Integrity that can make kernel vulnerabilities more difficult to exploit: https://clang.llvm.org/docs/ControlFlowIntegrity.html > This feels like it will end up being a game of whack-a-mole as code > could be introduced that tickles known bugs on older toolchains. I'm not sure this is much different from dealing with older versions of the existing toolchain. Otherwise, we wouldn't need cc-version or other similar macros, for example. Sami
On Thu, Nov 16, 2017 at 08:41:01AM -0800, Sami Tolvanen wrote: > On Thu, Nov 16, 2017 at 11:50:12AM +0000, Will Deacon wrote: > > Why don't we just not do LTO if the toolchain is busted? > > Because LTO can not only potentially improve performance, especially > when combined with PGO (Profile Guided Optimization), but it also > makes it possible to enable features like Control Flow Integrity that > can make kernel vulnerabilities more difficult to exploit: > > https://clang.llvm.org/docs/ControlFlowIntegrity.html > > > This feels like it will end up being a game of whack-a-mole as code > > could be introduced that tickles known bugs on older toolchains. > > I'm not sure this is much different from dealing with older versions > of the existing toolchain. Otherwise, we wouldn't need cc-version or > other similar macros, for example. I think the big difference is that we have no compelling need to support older versions of clang or gold. Will
diff --git a/arch/arm64/kernel/module.lds b/arch/arm64/kernel/module.lds index f7c9781a9d48..eacb5c67f61e 100644 --- a/arch/arm64/kernel/module.lds +++ b/arch/arm64/kernel/module.lds @@ -1,4 +1,4 @@ SECTIONS { - .plt (NOLOAD) : { BYTE(0) } - .init.plt (NOLOAD) : { BYTE(0) } + .plt : { BYTE(0) } + .init.plt : { BYTE(0) } }
CONFIG_CLANG_LTO depends on GNU gold and due to a known bug, the linker crashes when ARM64_MODULE_PLTS is enabled: https://sourceware.org/bugzilla/show_bug.cgi?id=14592 To work around the problem, this change removes NOLOAD from .plt and .init.plt, which allows us to link modules with ld.gold. Signed-off-by: Sami Tolvanen <samitolvanen@google.com> --- arch/arm64/kernel/module.lds | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)