From patchwork Fri Apr 28 09:51:09 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hou Wenlong X-Patchwork-Id: 13226174 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 7F1EBC77B60 for ; Fri, 28 Apr 2023 09:57:22 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.527226.819591 (Exim 4.92) (envelope-from ) id 1psKql-00021c-WD; Fri, 28 Apr 2023 09:57:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 527226.819591; Fri, 28 Apr 2023 09:57:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1psKql-0001z7-QA; Fri, 28 Apr 2023 09:57:11 +0000 Received: by outflank-mailman (input) for mailman id 527226; Fri, 28 Apr 2023 09:53:35 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1psKnH-0001iA-Dx for xen-devel@lists.xenproject.org; Fri, 28 Apr 2023 09:53:35 +0000 Received: from out0-200.mail.aliyun.com (out0-200.mail.aliyun.com [140.205.0.200]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 88079f65-e5aa-11ed-8611-37d641c3527e; Fri, 28 Apr 2023 11:53:33 +0200 (CEST) Received: from localhost(mailfrom:houwenlong.hwl@antgroup.com fp:SMTPD_---.STFoGYl_1682675602) by smtp.aliyun-inc.com; Fri, 28 Apr 2023 17:53:23 +0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 88079f65-e5aa-11ed-8611-37d641c3527e X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R211e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018047212;MF=houwenlong.hwl@antgroup.com;NM=1;PH=DS;RN=17;SR=0;TI=SMTPD_---.STFoGYl_1682675602; From: "Hou Wenlong" To: linux-kernel@vger.kernel.org Cc: "Thomas Garnier" , "Lai Jiangshan" , "Kees Cook" , "Hou Wenlong" , "Juergen Gross" , "Boris Ostrovsky" , "Darren Hart" , "Andy Shevchenko" , "Thomas Gleixner" , "Ingo Molnar" , "Borislav Petkov" , "Dave Hansen" , , "H. Peter Anvin" , , Subject: [PATCH RFC 29/43] x86/PVH: Adapt PVH booting for PIE support Date: Fri, 28 Apr 2023 17:51:09 +0800 Message-Id: X-Mailer: git-send-email 2.31.1 In-Reply-To: References: MIME-Version: 1.0 If PIE is enabled, all symbol references would be RIP-relative. However, PVH booting runs in low address space, which could cause wrong x86_init callbacks assignment. Since init_top_pgt has building high kernel address mapping, let PVH booting runs in high address space to make all things right. PVH booting assumes that no relocation happened. Since the kernel compile address is still in top 2G, so it is allowed to use R_X86_64_32S for symbol references in pvh_start_xen(). Signed-off-by: Hou Wenlong Cc: Thomas Garnier Cc: Lai Jiangshan Cc: Kees Cook --- arch/x86/platform/pvh/head.S | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/arch/x86/platform/pvh/head.S b/arch/x86/platform/pvh/head.S index 5842fe0e4f96..09518d4de042 100644 --- a/arch/x86/platform/pvh/head.S +++ b/arch/x86/platform/pvh/head.S @@ -94,6 +94,13 @@ SYM_CODE_START_LOCAL(pvh_start_xen) /* 64-bit entry point. */ .code64 1: +#ifdef CONFIG_X86_PIE + movabs $2f, %rax + ANNOTATE_RETPOLINE_SAFE + jmp *%rax +2: + ANNOTATE_NOENDBR // above +#endif /* Set base address in stack canary descriptor. */ mov $MSR_GS_BASE,%ecx #if defined(CONFIG_STACKPROTECTOR_FIXED) @@ -149,9 +156,15 @@ SYM_CODE_END(pvh_start_xen) .section ".init.data","aw" .balign 8 SYM_DATA_START_LOCAL(gdt) + /* + * Use an ASM_PTR (quad on x64) for _pa(gdt_start) because PIE requires + * a pointer size storage value before applying the relocation. On + * 32-bit _ASM_PTR will be a long which is aligned the space needed for + * relocation. + */ .word gdt_end - gdt_start - .long _pa(gdt_start) - .word 0 + _ASM_PTR _pa(gdt_start) + .balign 8 SYM_DATA_END(gdt) SYM_DATA_START_LOCAL(gdt_start) .quad 0x0000000000000000 /* NULL descriptor */