diff mbox

[v2,10/18] arm64: add a workaround for GNU gold with ARM64_MODULE_PLTS

Message ID 20171115213428.22559-11-samitolvanen@google.com (mailing list archive)
State New, archived
Headers show

Commit Message

Sami Tolvanen Nov. 15, 2017, 9:34 p.m. UTC
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(-)

Comments

Will Deacon Nov. 16, 2017, 11:50 a.m. UTC | #1
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
Sami Tolvanen Nov. 16, 2017, 4:41 p.m. UTC | #2
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
Will Deacon Nov. 16, 2017, 6:47 p.m. UTC | #3
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 mbox

Patch

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) }
 }