Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp2294131ybe; Sat, 7 Sep 2019 12:39:48 -0700 (PDT) X-Google-Smtp-Source: APXvYqwe1wugbOOgCUduNINAkrQIhbBD8BWyolf0xmfwXaj0xt/0yv7zvZEDowj/i+2RLjPCeAns X-Received: by 2002:a63:1:: with SMTP id 1mr13785591pga.162.1567885188722; Sat, 07 Sep 2019 12:39:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567885188; cv=none; d=google.com; s=arc-20160816; b=HKX7VZ3p3i8o8JGRY1AzAdm7p2joaD1rSXEhpWPHbiCVLKgPTZEgtJqMmMLRcPMBfs x9SDFVvQTfDix9V8nQP3Z2yJji//nE6xJ+aeUtFqgTFZy1DoZIQ1zkDfvxS0Cz+Gc8ah /R84IMveTQmkphnzX4mOzqbL0OY7EowKOIOl8m6b7CArQJpNGPgKu3kKGZkMX8eK/uNA 4dc9hP6W56nBHIqZTKrgzWNMxgkRCRc2GhgjMbywMhJBrNPB5I7AS/aAe5Grg0MwgZu2 vMJQLzHxJ8ZUl+Pbkx6eqkwHyknt4/r3KwfoJmMmkmrTtB8UnzI/mqDXSNqC5Ivs/oWA uHXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :robot-unsubscribe:robot-id:message-id:mime-version:references :in-reply-to:cc:subject:to:reply-to:from:date; bh=6q4iz2KhNuUMxhl1R7WmXAZn1Sk3dlbeQUMwRnZv74M=; b=zrBi/Kojy7fprXpFDa61z9r/+Zro1IgZibARpjAQHVlqSFfClORTCp+CLkQoxa0NVd wrKeT/0+DqENY8V/iFqaMKGl9Ke74EUkoELtLAcbMCjvatcrOiDMzJuASeMGzMM0T5qr 4hvKy+CLwDmuGqCMG4ag5+4GNkTKiqsvqmxoIb4AqDCXYrHvO6/JCJ2NaEzPL0jmB6V0 kv4lG7NBcnOPGsC5oz5+vvAMMn33lcO8FehLv49OWFtlIq44iOGoIcIxbdA5cBTCVqMx MsGoHOg02L+t9tfuElfOpY8KsVreGGWlja8HJpBXXl7zDvB2Udlu9MO4ih7433qeMAL6 aD4g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h12si1214092plk.331.2019.09.07.12.39.33; Sat, 07 Sep 2019 12:39:48 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2392406AbfIFSz6 (ORCPT + 99 others); Fri, 6 Sep 2019 14:55:58 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:48246 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387606AbfIFSz5 (ORCPT ); Fri, 6 Sep 2019 14:55:57 -0400 Received: from [5.158.153.53] (helo=tip-bot2.lab.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1i6JOW-0000DR-6e; Fri, 06 Sep 2019 20:55:40 +0200 Received: from [127.0.1.1] (localhost [IPv6:::1]) by tip-bot2.lab.linutronix.de (Postfix) with ESMTP id 70BF61C0744; Fri, 6 Sep 2019 20:55:39 +0200 (CEST) Date: Fri, 06 Sep 2019 18:55:39 -0000 From: "tip-bot2 for Steve Wahl" Reply-to: linux-kernel@vger.kernel.org To: linux-tip-commits@vger.kernel.org Subject: [tip: x86/urgent] x86/purgatory: Change compiler flags from -mcmodel=kernel to -mcmodel=large to fix kexec relocation errors Cc: Vaibhav Rustagi , Andreas Smas , Steve Wahl , Nick Desaulniers , Borislav Petkov , "H. Peter Anvin" , Linus Torvalds , Peter Zijlstra , Thomas Gleixner , clang-built-linux@googlegroups.com, dimitri.sivanich@hpe.com, mike.travis@hpe.com, russ.anderson@hpe.com, Ingo Molnar , linux-kernel@vger.kernel.org In-Reply-To: <20190905202346.GA26595@swahl-linux> References: <20190905202346.GA26595@swahl-linux> MIME-Version: 1.0 Message-ID: <156779613930.24167.1219380492780490078.tip-bot2@tip-bot2> X-Mailer: tip-git-log-daemon Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The following commit has been merged into the x86/urgent branch of tip: Commit-ID: e16c2983fba0fa6763e43ad10916be35e3d8dc05 Gitweb: https://git.kernel.org/tip/e16c2983fba0fa6763e43ad10916be35e3d8dc05 Author: Steve Wahl AuthorDate: Thu, 05 Sep 2019 15:23:46 -05:00 Committer: Ingo Molnar CommitterDate: Fri, 06 Sep 2019 09:50:56 +02:00 x86/purgatory: Change compiler flags from -mcmodel=kernel to -mcmodel=large to fix kexec relocation errors The last change to this Makefile caused relocation errors when loading a kdump kernel. Restore -mcmodel=large (not -mcmodel=kernel), -ffreestanding, and -fno-zero-initialized-bsss, without reverting to the former practice of resetting KBUILD_CFLAGS. Purgatory.ro is a standalone binary that is not linked against the rest of the kernel. Its image is copied into an array that is linked to the kernel, and from there kexec relocates it wherever it desires. With the previous change to compiler flags, the error "kexec: Overflow in relocation type 11 value 0x11fffd000" was encountered when trying to load the crash kernel. This is from kexec code trying to relocate the purgatory.ro object. >From the error message, relocation type 11 is R_X86_64_32S. The x86_64 ABI says: "The R_X86_64_32 and R_X86_64_32S relocations truncate the computed value to 32-bits. The linker must verify that the generated value for the R_X86_64_32 (R_X86_64_32S) relocation zero-extends (sign-extends) to the original 64-bit value." This type of relocation doesn't work when kexec chooses to place the purgatory binary in memory that is not reachable with 32 bit addresses. The compiler flag -mcmodel=kernel allows those type of relocations to be emitted, so revert to using -mcmodel=large as was done before. Also restore the -ffreestanding and -fno-zero-initialized-bss flags because they are appropriate for a stand alone piece of object code which doesn't explicitly zero the bss, and one other report has said undefined symbols are encountered without -ffreestanding. These identical compiler flag changes need to happen for every object that becomes part of the purgatory.ro object, so gather them together first into PURGATORY_CFLAGS_REMOVE and PURGATORY_CFLAGS, and then apply them to each of the objects that have C source. Do not apply any of these flags to kexec-purgatory.o, which is not part of the standalone object but part of the kernel proper. Tested-by: Vaibhav Rustagi Tested-by: Andreas Smas Signed-off-by: Steve Wahl Reviewed-by: Nick Desaulniers Cc: Borislav Petkov Cc: H. Peter Anvin Cc: Linus Torvalds Cc: None Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: clang-built-linux@googlegroups.com Cc: dimitri.sivanich@hpe.com Cc: mike.travis@hpe.com Cc: russ.anderson@hpe.com Fixes: b059f801a937 ("x86/purgatory: Use CFLAGS_REMOVE rather than reset KBUILD_CFLAGS") Link: https://lkml.kernel.org/r/20190905202346.GA26595@swahl-linux Signed-off-by: Ingo Molnar --- arch/x86/purgatory/Makefile | 35 +++++++++++++++++++---------------- 1 file changed, 19 insertions(+), 16 deletions(-) diff --git a/arch/x86/purgatory/Makefile b/arch/x86/purgatory/Makefile index 8901a1f..10fb42d 100644 --- a/arch/x86/purgatory/Makefile +++ b/arch/x86/purgatory/Makefile @@ -18,37 +18,40 @@ targets += purgatory.ro KASAN_SANITIZE := n KCOV_INSTRUMENT := n +# These are adjustments to the compiler flags used for objects that +# make up the standalone purgatory.ro + +PURGATORY_CFLAGS_REMOVE := -mcmodel=kernel +PURGATORY_CFLAGS := -mcmodel=large -ffreestanding -fno-zero-initialized-in-bss + # Default KBUILD_CFLAGS can have -pg option set when FTRACE is enabled. That # in turn leaves some undefined symbols like __fentry__ in purgatory and not # sure how to relocate those. ifdef CONFIG_FUNCTION_TRACER -CFLAGS_REMOVE_sha256.o += $(CC_FLAGS_FTRACE) -CFLAGS_REMOVE_purgatory.o += $(CC_FLAGS_FTRACE) -CFLAGS_REMOVE_string.o += $(CC_FLAGS_FTRACE) -CFLAGS_REMOVE_kexec-purgatory.o += $(CC_FLAGS_FTRACE) +PURGATORY_CFLAGS_REMOVE += $(CC_FLAGS_FTRACE) endif ifdef CONFIG_STACKPROTECTOR -CFLAGS_REMOVE_sha256.o += -fstack-protector -CFLAGS_REMOVE_purgatory.o += -fstack-protector -CFLAGS_REMOVE_string.o += -fstack-protector -CFLAGS_REMOVE_kexec-purgatory.o += -fstack-protector +PURGATORY_CFLAGS_REMOVE += -fstack-protector endif ifdef CONFIG_STACKPROTECTOR_STRONG -CFLAGS_REMOVE_sha256.o += -fstack-protector-strong -CFLAGS_REMOVE_purgatory.o += -fstack-protector-strong -CFLAGS_REMOVE_string.o += -fstack-protector-strong -CFLAGS_REMOVE_kexec-purgatory.o += -fstack-protector-strong +PURGATORY_CFLAGS_REMOVE += -fstack-protector-strong endif ifdef CONFIG_RETPOLINE -CFLAGS_REMOVE_sha256.o += $(RETPOLINE_CFLAGS) -CFLAGS_REMOVE_purgatory.o += $(RETPOLINE_CFLAGS) -CFLAGS_REMOVE_string.o += $(RETPOLINE_CFLAGS) -CFLAGS_REMOVE_kexec-purgatory.o += $(RETPOLINE_CFLAGS) +PURGATORY_CFLAGS_REMOVE += $(RETPOLINE_CFLAGS) endif +CFLAGS_REMOVE_purgatory.o += $(PURGATORY_CFLAGS_REMOVE) +CFLAGS_purgatory.o += $(PURGATORY_CFLAGS) + +CFLAGS_REMOVE_sha256.o += $(PURGATORY_CFLAGS_REMOVE) +CFLAGS_sha256.o += $(PURGATORY_CFLAGS) + +CFLAGS_REMOVE_string.o += $(PURGATORY_CFLAGS_REMOVE) +CFLAGS_string.o += $(PURGATORY_CFLAGS) + $(obj)/purgatory.ro: $(PURGATORY_OBJS) FORCE $(call if_changed,ld)