archive mirror
 help / color / mirror / Atom feed
From: "tip-bot2 for Arvind Sankar" <>
Cc: Nick Desaulniers <>,
	Arvind Sankar <>,
	Ingo Molnar <>,
	Sedat Dilek <>,
	Ard Biesheuvel <>,, x86 <>,
	LKML <>
Subject: [tip: x86/urgent] x86/boot/compressed: Disable relocation relaxation
Date: Mon, 14 Sep 2020 17:16:27 -0000	[thread overview]
Message-ID: <160010378780.15536.10220665698122173682.tip-bot2@tip-bot2> (raw)
In-Reply-To: <>

The following commit has been merged into the x86/urgent branch of tip:

Commit-ID:     09e43968db40c33a73e9ddbfd937f46d5c334924
Author:        Arvind Sankar <>
AuthorDate:    Tue, 11 Aug 2020 20:43:08 -04:00
Committer:     Ingo Molnar <>
CommitterDate: Mon, 14 Sep 2020 11:14:45 +02:00

x86/boot/compressed: Disable relocation relaxation

The x86-64 psABI [0] specifies special relocation types
(R_X86_64_[REX_]GOTPCRELX) for indirection through the Global Offset
Table, semantically equivalent to R_X86_64_GOTPCREL, which the linker
can take advantage of for optimization (relaxation) at link time. This
is supported by LLD and binutils versions 2.26 onwards.

The compressed kernel is position-independent code, however, when using
LLD or binutils versions before 2.27, it must be linked without the -pie
option. In this case, the linker may optimize certain instructions into
a non-position-independent form, by converting foo@GOTPCREL(%rip) to $foo.

This potential issue has been present with LLD and binutils-2.26 for a
long time, but it has never manifested itself before now:

- LLD and binutils-2.26 only relax
	movq	foo@GOTPCREL(%rip), %reg
	leaq	foo(%rip), %reg
  which is still position-independent, rather than
	mov	$foo, %reg
  which is permitted by the psABI when -pie is not enabled.

- GCC happens to only generate GOTPCREL relocations on mov instructions.

- CLang does generate GOTPCREL relocations on non-mov instructions, but
  when building the compressed kernel, it uses its integrated assembler
  (due to the redefinition of KBUILD_CFLAGS dropping -no-integrated-as),
  which has so far defaulted to not generating the GOTPCRELX

Nick Desaulniers reports [1,2]:

  "A recent change [3] to a default value of configuration variable
   (ENABLE_X86_RELAX_RELOCATIONS OFF -> ON) in LLVM now causes Clang's
   integrated assembler to emit R_X86_64_GOTPCRELX/R_X86_64_REX_GOTPCRELX
   relocations. LLD will relax instructions with these relocations based
   on whether the image is being linked as position independent or not.
   When not, then LLD will relax these instructions to use absolute
   addressing mode (R_RELAX_GOT_PC_NOPIC). This causes kernels built with
   Clang and linked with LLD to fail to boot."

Patch series [4] is a solution to allow the compressed kernel to be
linked with -pie unconditionally, but even if merged is unlikely to be
backported. As a simple solution that can be applied to stable as well,
prevent the assembler from generating the relaxed relocation types using
the -mrelax-relocations=no option. For ease of backporting, do this


Reported-by: Nick Desaulniers <>
Signed-off-by: Arvind Sankar <>
Signed-off-by: Ingo Molnar <>
Tested-by: Nick Desaulniers <>
Tested-by: Sedat Dilek <>
Acked-by: Ard Biesheuvel <>
Reviewed-by: Nick Desaulniers <>
 arch/x86/boot/compressed/Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/boot/compressed/Makefile b/arch/x86/boot/compressed/Makefile
index 3962f59..ff7894f 100644
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@ -43,6 +43,8 @@ KBUILD_CFLAGS += -Wno-pointer-sign
 KBUILD_CFLAGS += $(call cc-option,-fmacro-prefix-map=$(srctree)/=)
 KBUILD_CFLAGS += -fno-asynchronous-unwind-tables
+# Disable relocation relaxation in case the link is not PIE.
+KBUILD_CFLAGS += $(call as-option,-Wa$(comma)-mrelax-relocations=no)

  parent reply	other threads:[~2020-09-14 17:18 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-07 19:41 [PATCH] x86/boot: avoid relaxable symbols with Clang Nick Desaulniers
2020-08-07 21:29 ` Arvind Sankar
2020-08-07 21:54   ` Nick Desaulniers
2020-08-08  1:43     ` Arvind Sankar
2020-08-10 18:32       ` Nick Desaulniers
2020-08-11 17:36         ` [PATCH] x86/boot/compressed: Disable relocation relaxation for non-pie link Arvind Sankar
2020-08-11 17:58           ` Nick Desaulniers
2020-08-11 22:44             ` Arvind Sankar
2020-08-11 23:04               ` Nick Desaulniers
2020-08-11 23:43                 ` Arvind Sankar
2020-08-11 23:51                   ` Nick Desaulniers
2020-08-12  0:41                     ` Arvind Sankar
2020-08-12  0:43                       ` [PATCH v2] x86/boot/compressed: Disable relocation relaxation Arvind Sankar
2020-08-12 17:42                         ` Nick Desaulniers
2020-08-15 15:49                         ` Sedat Dilek
2020-08-15 20:56                           ` Nick Desaulniers
2020-08-15 21:09                             ` Sedat Dilek
2020-08-25 14:56                             ` Arvind Sankar
2020-09-04 15:23                               ` Arvind Sankar
2020-09-13 22:34                               ` Arvind Sankar
2020-09-14  5:43                                 ` Ard Biesheuvel
2020-09-14  9:16                                   ` Ingo Molnar
2020-09-14  9:35                                     ` Sedat Dilek
2020-09-14 17:16                         ` tip-bot2 for Arvind Sankar [this message]
2020-08-12 17:39                       ` [PATCH] x86/boot/compressed: Disable relocation relaxation for non-pie link Nick Desaulniers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=160010378780.15536.10220665698122173682.tip-bot2@tip-bot2 \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).