Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp4344ybe; Thu, 5 Sep 2019 16:25:32 -0700 (PDT) X-Google-Smtp-Source: APXvYqxLpR2O3j8HVXyJrgClkT7u08ZbSiaWP8ZLX926YwlRFiQQCb/e6NZASSwswjuVPk/NqiVb X-Received: by 2002:a17:90a:ac0a:: with SMTP id o10mr6478989pjq.139.1567725932363; Thu, 05 Sep 2019 16:25:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567725932; cv=none; d=google.com; s=arc-20160816; b=Ol2AwesC8p1IZ7EEuoE0beAO1/4pKaURHt/blAbTADO5Ti4Gs+hHtkZh1TLxNsIHdH rDVgzraFtcnwvL3aWRsxuMiSc9RT/dNZS9UkeSh2t6m1pZzsS9sehI5sfLZkuddTcjoa UZv4LZ8QVBsjnCp5qdJQcbbNWETAQ//ghDJQJW9J8boGj/Wr5oKL0yGgKU2dJgSjsxw2 tnHjWlExlpSN7Tq9IhaKAOoN1iuYUIPJE5e+jzpOKxvRwkIxY4zAdBUFzGtPyza/igP1 LcNeKOvfvcVb5x5S0PbVbZTSFLXm/So6+16KVihqx3miP2JiThTobf8k61GU48hPP8c5 pHiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:content-disposition :mime-version:message-id:subject:to:from:date; bh=sAZ55aak4C1PfOzZ8kFKYnHHT5hCn/juM84yXDtu/oY=; b=e8a5ix3WqvOTyRwRznuu8gtAYehudSZ0AX6/wOHni0uYsirx9e4oF0tFeDtAswcCl0 uxDC81VjXC9IMueTNHqnPmDMH3zofrJ5raQYjVN++Wd1Lw4BVQax2DLuv31YwBMVrjoL 5XogpqoKNim1kXKa6NDeEYy9aU5PzibolVLtGTpe1IPz2fbwW0OKBfJs9hSxCLtFfNzw anQu6g1o7j+k2IducMBDvrVghmg5bOMq6+PPp0Kknx97QU67QfF+un1tCOjAxb52Z85z y7BHQVITeAr0Y4t/Lr5RrEqDyJfxXUvx0t1tShKx0ez1761E7FvMnzmepsvJ0aBvZUZB eKSg== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=hpe.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v4si3564280pfn.132.2019.09.05.16.25.15; Thu, 05 Sep 2019 16:25:32 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=hpe.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389853AbfIEUYF (ORCPT + 99 others); Thu, 5 Sep 2019 16:24:05 -0400 Received: from mx0a-002e3701.pphosted.com ([148.163.147.86]:48804 "EHLO mx0a-002e3701.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388502AbfIEUYF (ORCPT ); Thu, 5 Sep 2019 16:24:05 -0400 Received: from pps.filterd (m0150241.ppops.net [127.0.0.1]) by mx0a-002e3701.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x85KLZ1G017534; Thu, 5 Sep 2019 20:23:47 GMT Received: from g4t3425.houston.hpe.com (g4t3425.houston.hpe.com [15.241.140.78]) by mx0a-002e3701.pphosted.com with ESMTP id 2uu6ews8pd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 05 Sep 2019 20:23:47 +0000 Received: from g9t2301.houston.hpecorp.net (g9t2301.houston.hpecorp.net [16.220.97.129]) by g4t3425.houston.hpe.com (Postfix) with ESMTP id F41FA8D; Thu, 5 Sep 2019 20:23:46 +0000 (UTC) Received: from swahl-linux (swahl-linux.americas.hpqcorp.net [10.33.153.21]) by g9t2301.houston.hpecorp.net (Postfix) with ESMTP id 6007648; Thu, 5 Sep 2019 20:23:46 +0000 (UTC) Date: Thu, 5 Sep 2019 15:23:46 -0500 From: Steve Wahl To: linux-kernel@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , x86@kernel.org, Nick Desaulniers , Steve Wahl , clang-built-linux@googlegroups.com, vaibhavrustagi@google.com, russ.anderson@hpe.com, dimitri.sivanich@hpe.com, mike.travis@hpe.com Subject: [PATCH v2] x86/purgatory: Change compiler flags to avoid relocation errors. Message-ID: <20190905202346.GA26595@swahl-linux> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.12.1 (2019-06-15) X-HPE-SCL: -1 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.70,1.0.8 definitions=2019-09-05_07:2019-09-04,2019-09-05 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 malwarescore=0 mlxlogscore=985 impostorscore=0 suspectscore=0 adultscore=0 bulkscore=0 priorityscore=1501 mlxscore=0 clxscore=1011 phishscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1906280000 definitions=main-1909050188 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Fixes: b059f801a937 ("x86/purgatory: Use CFLAGS_REMOVE rather than reset KBUILD_CFLAGS") Signed-off-by: Steve Wahl Reviewed-by: Nick Desaulniers Tested-by: Vaibhav Rustagi Tested-by: Andreas Smas --- PATCH v2: Incorporated suggested changes to the commit message. 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 8901a1f89cf5..10fb42da0007 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) -- 2.21.0 -- Steve Wahl, Hewlett Packard Enterprise