Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp2576550pxa; Fri, 7 Aug 2020 14:57:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzga0ZGXTd2kTT30aXHKcFtEkTJzEq6lLp88XpT0Tr8y1Y62tF+fuiU1mC+uB2icEGabU3E X-Received: by 2002:aa7:c406:: with SMTP id j6mr10620447edq.143.1596837440204; Fri, 07 Aug 2020 14:57:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596837440; cv=none; d=google.com; s=arc-20160816; b=qzrDSydZUzfhZN9Td9c61ZizClqTIVn8bWhHOB7oZdUVJggvoXxt6CTQllQKTpiywg 8avC4BLVtNyR6IVaOpkIlVgcCV5sTRzeN/BMQAYZtaU86WEWf/DNfkqjGV4I1dYMERpk m0uSj7MUFUEukmvoFC8Ve9V9UWA1vC2kE8YDNivfhhycUTw58dENZzJ+cOOrFh3EdVR8 7m2Vq+lK/fxZ41LsjxlVtotBU6ESRRzZ4kOL/rv4n0S1KiWStSsrsGLl/QbBfY62tOG5 8x+8KEViN4SAqC2gciGB95QtIjLwTLAXiZ9t8QWGPqMV4Vv9hNOk+0htMjct+U28cJrK ZR8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=PvRGcDuizgzYHfGqKWM/eyvjCExelLzyI7VykszthhA=; b=n/nz6gdiBB+IKIhLDNbantgGSz+/NozUoL2g+J2hcJMNMeWxTCaTxqaAhnjxj4Gm5C Zal5+xKMwIC1bOeWLJAsBiQBD1F2kaagS6kASAWdNIkHNlt/ynnsokTGh7xwvFmeNUND w/d/n4tUWDyjywWUAFCTj7fbFbcxN0SSSoEHcB9IhkFFWGXQSnoMi23O9RT5V2MFXt89 s55s13GqCV9JRH1ios+rckXTWkUWe4az+p+ZLNsHRQBGiBN8TvatvxrVIUz8HnPL3tHA yL7fae73oJ90iipszhHfooWQBmvrSvsbtHMbb7/2VQtNdJe2k2z8b+fO6IXtnPHCXUfV rF9A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Yv3wn2cr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y10si6074728edu.397.2020.08.07.14.56.42; Fri, 07 Aug 2020 14:57:20 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Yv3wn2cr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726426AbgHGVyx (ORCPT + 99 others); Fri, 7 Aug 2020 17:54:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57392 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726015AbgHGVyx (ORCPT ); Fri, 7 Aug 2020 17:54:53 -0400 Received: from mail-pl1-x644.google.com (mail-pl1-x644.google.com [IPv6:2607:f8b0:4864:20::644]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EE3A8C061757 for ; Fri, 7 Aug 2020 14:54:52 -0700 (PDT) Received: by mail-pl1-x644.google.com with SMTP id t10so1795098plz.10 for ; Fri, 07 Aug 2020 14:54:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PvRGcDuizgzYHfGqKWM/eyvjCExelLzyI7VykszthhA=; b=Yv3wn2cry//B5ePdcUe9owHQplszhGtCIZLuMcKnhnRVcwYMr1OntJO+RwRDHkjzZm KVpZpKmvU9Px8Ov1zowsDGijOLGFq9U3ngiMz1FXua4PeJxyATVWA7wQ9meiQMnN+wTH ZjMHKPdnKSijRG7cXqJegeYTOzzK0aa3Bf/0HShMuyCLlOk6uYS6a2XTjfDiC79BiH5U ngfTPDWWlfeAJv8319CDUA4N0R6gsZUvmQavPMkpAZ5EiY80I7DaiNmAqCmnROpaHLfz wHW8a1oyqw4BWNbmXveSyNuAT/Yp6gLGN7xw7m+cxIOlEgA/CivLyyF7gHc+Fb7dEFXa sK6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PvRGcDuizgzYHfGqKWM/eyvjCExelLzyI7VykszthhA=; b=teGNUyZzTR1ZXehSWy5O8XWrLixH4LTo5apAIgujbyRILJWq1xfAiqjhcIyp+L1mki lBvkT9PtvfjxTQyHesOCPc7cDVnxTN9V0HaPMfh9N5gfm3WXAzFFWgpSLjNBY9djHxDs muaN4f0SDIetarqi5ND8DDjTg/f+VgZBfczEIycMMoXH9Eu2b4QNNae0OJhQxp+sZ/Wz w2heDBVDRM0OqcEPAJuo8c8PrkRpMYebb76OgJ9uMh7Y0L5bd8CPrRhrkxSFERhQcYcT Lgs6KPOTK4pOKCpUUSkYJBhgAoaeu7ZEcIOHjtvIbTT1UhERCebKozixLji6hVzMAZOs ebTw== X-Gm-Message-State: AOAM533aY4XsmCL2sMWj9bfCOSbApaKBOG/mbLH6LGYaiPn3GlJJE587 FOazsNum3S/o8U2t8TdnAzyeKyOu9h150WsqXTsObw== X-Received: by 2002:a17:90a:3ad1:: with SMTP id b75mr14470579pjc.25.1596837291969; Fri, 07 Aug 2020 14:54:51 -0700 (PDT) MIME-Version: 1.0 References: <20200807194100.3570838-1-ndesaulniers@google.com> <20200807212914.GB1454138@rani.riverdale.lan> In-Reply-To: <20200807212914.GB1454138@rani.riverdale.lan> From: Nick Desaulniers Date: Fri, 7 Aug 2020 14:54:39 -0700 Message-ID: Subject: Re: [PATCH] x86/boot: avoid relaxable symbols with Clang To: Arvind Sankar Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Fangrui Song , clang-built-linux , e5ten.arch@gmail.com, "# 3.4.x" , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , "H. Peter Anvin" , Masahiro Yamada , Ard Biesheuvel , Kees Cook , Dmitry Golovin , Marco Elver , Nick Terrell , Daniel Kiper , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Aug 7, 2020 at 2:29 PM Arvind Sankar wrote: > > 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). Thanks for taking a look, and the feedback. I appreciate it! $ gcc --version | head -n 1 gcc (Debian 9.3.0-11) 9.3.0 $ make -j71 clean defconfig bzImage $ llvm-readelf -r arch/x86/boot/compressed/*.o | grep -e R_X86_64_GOTPCRELX -e R_X86_64_REX_GOTPCRELX 0000000000000114 000000120000002a R_X86_64_REX_GOTPCRELX 0000000000000000 trampoline_32bit_src - 4 $ llvm-readelf -r arch/x86/boot/compressed/vmlinux | grep -e R_X86_64_GOTPCRELX -e R_X86_64_REX_GOTPCRELX $ So it looks like yes. I guess then we'd need to add a check for CONFIG_LD_IS_LLD and CONFIG_CC_IS_GCC and binutils version is 2.26+? I don't mind adding support for that combination, but I'd like to skip it in this patch for the sake of backporting something small to stable to get our CI green ASAP, since CONFIG_LD_IS_LLD probably doesn't exist for those stable branches, which will complicate the backport of such a patch. So I'd do it in a follow up patch if we're cool with that? > 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. I am, too. I didn't specify which symbol was problematic or put this flag on just one object file, because it's likely that there's an issue with multiple symbols in multiple object files, though it's just _pgtable that causes observable boot failures. > 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/ Oh, indeed. > > 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 That's why I was careful to note in the commit message that it was Clang's integrated assembler (assembler job) vs Clang (compiler job) itself that was producing these. May I add precisely: ``` 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. ``` with your suggested-by tag for a v2? > 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. -- Thanks, ~Nick Desaulniers