All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arvind Sankar <nivedita@alum.mit.edu>
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Fangrui Song <maskray@google.com>,
	clang-built-linux@googlegroups.com, e5ten.arch@gmail.com,
	stable@vger.kernel.org, x86@kernel.org,
	"H. Peter Anvin" <hpa@zytor.com>,
	Masahiro Yamada <masahiroy@kernel.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Kees Cook <keescook@chromium.org>,
	Arvind Sankar <nivedita@alum.mit.edu>,
	Dmitry Golovin <dima@golovin.in>, Marco Elver <elver@google.com>,
	Nick Terrell <terrelln@fb.com>,
	Daniel Kiper <daniel.kiper@oracle.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86/boot: avoid relaxable symbols with Clang
Date: Fri, 7 Aug 2020 17:29:14 -0400	[thread overview]
Message-ID: <20200807212914.GB1454138@rani.riverdale.lan> (raw)
In-Reply-To: <20200807194100.3570838-1-ndesaulniers@google.com>

On Fri, Aug 07, 2020 at 12:41:00PM -0700, Nick Desaulniers wrote:
> A recent change 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.

It could also cause kernels compiled with gcc and linked with LLD to
fail in the same way, no? The gcc/gas combination will generate the
relaxed relocations from I think gas-2.26 onward. Although the only
troublesome symbol in the case of gcc/gas is trampoline_32bit_src,
referenced from pgtable_64.c (gcc doesn't use a GOTPC reloc for _pgtable
etc).

I'm a bit surprised you were able to boot with just _pgtable fixed
(looking at the CBL issue), there are quite a few more GOTPC relocs with
clang -- maybe LLD isn't doing all the optimizations it could yet.

This potential issue was mentioned [0] in one of the earlier threads
(see last paragraph).

[0] https://lore.kernel.org/lkml/20200526191411.GA2380966@rani.riverdale.lan/

> 
> Also, the LLVM commit notes that these relocation types aren't supported
> until binutils 2.26. Since we support binutils 2.23+, avoid the
> relocations regardless of linker.

Note that the GNU assembler won't support the option to disable the
relaxations until 2.26, when they were added.

However, it turns out that clang always uses the integrated assembler
for the decompressor (and the EFI stub) because the no-integrated-as
option gets dropped when building these pieces, due to redefinition of
KBUILD_CFLAGS. You might want to mention this in the commit log or a
comment to explain why using the option unconditionally is safe. It
might need to be made conditional if the CFLAGS ever gets fixed to
maintain no-integrated-as.

Thanks.

  reply	other threads:[~2020-08-07 21:29 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 [this message]
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: x86/urgent] " tip-bot2 for Arvind Sankar
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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=20200807212914.GB1454138@rani.riverdale.lan \
    --to=nivedita@alum.mit.edu \
    --cc=ardb@kernel.org \
    --cc=bp@alien8.de \
    --cc=clang-built-linux@googlegroups.com \
    --cc=daniel.kiper@oracle.com \
    --cc=dima@golovin.in \
    --cc=e5ten.arch@gmail.com \
    --cc=elver@google.com \
    --cc=hpa@zytor.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    --cc=maskray@google.com \
    --cc=mingo@redhat.com \
    --cc=ndesaulniers@google.com \
    --cc=stable@vger.kernel.org \
    --cc=terrelln@fb.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.