Received: by 2002:a05:6359:6284:b0:131:369:b2a3 with SMTP id se4csp3220621rwb; Mon, 7 Aug 2023 09:57:23 -0700 (PDT) X-Google-Smtp-Source: AGHT+IES6xWhMlbDoCYwY7Ps9GHNJyyQgOldmKv1SagjcbkCORecqXyWKx76jFzTodCSCL6uvM3j X-Received: by 2002:a17:902:cec4:b0:1bc:1d1b:2314 with SMTP id d4-20020a170902cec400b001bc1d1b2314mr10676847plg.26.1691427443061; Mon, 07 Aug 2023 09:57:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1691427443; cv=none; d=google.com; s=arc-20160816; b=ixotqD2ckGYnqim7EX8gugfGZroxMz+oo6Fgkh7anxBn3RDOuBQhkSPDEZHy/S71b1 o0pXdMxx71rd7cYOPRTSwlIslQnwZRKXhkJmuCefx/2UzX3H9rh3VRmqDG+WQSHrlAqW EOBYbZbAP3/kdv5jXbtdL1rJWChMHBSjp5lMfbOylHwHdBgFhgVLmGfbQIxG7gp2foop LEca+tNcQ1BE7l8Ba1OciajwPjwzoADGIAlR19NEoKCja6N96FvoHJpuw0Y1rSCJcDQc 7E2VhQkOH00iO+5Jgd+0Qr7c2BIiaPgL0xCJTt470j4VdbMhaSburX4j2972/MSi5GOR W03A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=vOBo24w4Q4DKzHC3R7yJXEfT/vzI0l5F34i3nh+9YhM=; fh=cABQbWJU7O0a+UPgHSiwUQ6sY/R0G63oUvu0DeYA5T8=; b=IPNI28ReiqnNiBchvtGKpg4LeX31quDlsl3LUjcydhmPdrIz5GAChncIpZFHrcjjmd DY8fGGO3Li/2ZJ5cIFJ50/VO52VhxvBXHsCqAGtQ0HclGTjWLJLLywB/ClvPu1dpdBCL N2RUhVgrLxvN+lljiojcHp4aUtxBF3UEzqiee8+PDgoJt/a0TkW8SeLVDog4FXeKaUHy EzGTKghi5iQUJ/qH17xRG4gmEKzC1c4Y8bltjP50JG5Yn4iooxvgGSp/yBJwVVknlxNO 7Va90sSz+YpJ1QiY3g0jldTdlno5kIp4Wt/5f3ymonR26wmbg92kRlDRLA378OQNP/TQ pTJg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="QG4/HQWE"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ld7-20020a170902fac700b001b9eda236b5si2856219plb.506.2023.08.07.09.57.10; Mon, 07 Aug 2023 09:57:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="QG4/HQWE"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231540AbjHGQ1t (ORCPT + 99 others); Mon, 7 Aug 2023 12:27:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34024 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229989AbjHGQ1q (ORCPT ); Mon, 7 Aug 2023 12:27:46 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6EA5E100; Mon, 7 Aug 2023 09:27:45 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 031DD61F1D; Mon, 7 Aug 2023 16:27:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DBA3AC433C9; Mon, 7 Aug 2023 16:27:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1691425664; bh=XjLX3hjHoLnvob8g9oghOOvEmelRZfiMIypqVk9Wd+A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=QG4/HQWEdu8J+ougIL4ouncC79JZEuEluWHBU20KqaWg7QopZHRYU7swdaojee8Yx ZEAeBvI/b4X6FU4jXI7giOOWmKI2AHm/0rJNu2B6lJeXWufSM2bRDMTwiwdzPaP4uU kImHyU3G6IK0f0dbR0c68ZpgQdSEgZbdR5uBp5+yGJeLeuW0eyBkDYn1uYvHrZXONo Zn1h6nW1STRZKY/SRjr5QfxMgRBbuRhBiFLz734s5ONKAv1FRgZrPMtnqcq5Or9Beu Hqu9bgTneQcgMSJEMalD09OfYZJaKdvvRUiNPV6D1+W3VeWs0/tPKd4JO/7K30T9VI FrbHtAWnJmXAw== From: Ard Biesheuvel To: linux-efi@vger.kernel.org Cc: linux-kernel@vger.kernel.org, Ard Biesheuvel , Borislav Petkov , Dave Hansen , Ingo Molnar , Thomas Gleixner Subject: [PATCH v9 01/23] x86/decompressor: Don't rely on upper 32 bits of GPRs being preserved Date: Mon, 7 Aug 2023 18:26:58 +0200 Message-Id: <20230807162720.545787-2-ardb@kernel.org> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20230807162720.545787-1-ardb@kernel.org> References: <20230807162720.545787-1-ardb@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Developer-Signature: v=1; a=openpgp-sha256; l=3520; i=ardb@kernel.org; h=from:subject; bh=XjLX3hjHoLnvob8g9oghOOvEmelRZfiMIypqVk9Wd+A=; b=owGbwMvMwCFmkMcZplerG8N4Wi2JIeWitPdvs4L+nRM+Njhf2X/7xrr+CU/2y266yDVL442p9 eKjlxKkO0pZGMQ4GGTFFFkEZv99t/P0RKla51myMHNYmUCGMHBxCsBEpDYzMixeLnZh4fTG6OTF 5qxLzb49EePU49pVLXc/7KKi93w23cMM/7PjbGe0KzgGvF1exluVGCB/+eny2c/e5AV088+5F1d swAMA X-Developer-Key: i=ardb@kernel.org; a=openpgp; fpr=F43D03328115A198C90016883D200E9CA6329909 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The 4-to-5 level mode switch trampoline disables long mode and paging in order to be able to flick the LA57 bit. According to section 3.4.1.1 of the x86 architecture manual [0], 64-bit GPRs might not retain the upper 32 bits of their contents across such a mode switch. Given that RBP, RBX and RSI are live at this point, preserve them on the stack, along with the return address that might be above 4G as well. [0] Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1: Basic Architecture "Because the upper 32 bits of 64-bit general-purpose registers are undefined in 32-bit modes, the upper 32 bits of any general-purpose register are not preserved when switching from 64-bit mode to a 32-bit mode (to protected mode or compatibility mode). Software must not depend on these bits to maintain a value after a 64-bit to 32-bit mode switch." Fixes: 194a9749c73d650c ("x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G") Signed-off-by: Ard Biesheuvel --- arch/x86/boot/compressed/head_64.S | 30 +++++++++++++++----- 1 file changed, 23 insertions(+), 7 deletions(-) diff --git a/arch/x86/boot/compressed/head_64.S b/arch/x86/boot/compressed/head_64.S index 03c4328a88cbd5d0..f732426d3b483139 100644 --- a/arch/x86/boot/compressed/head_64.S +++ b/arch/x86/boot/compressed/head_64.S @@ -459,11 +459,25 @@ SYM_CODE_START(startup_64) /* Save the trampoline address in RCX */ movq %rax, %rcx + /* Set up 32-bit addressable stack */ + leaq TRAMPOLINE_32BIT_STACK_END(%rcx), %rsp + /* - * Load the address of trampoline_return() into RDI. - * It will be used by the trampoline to return to the main code. + * Preserve live 64-bit registers on the stack: this is necessary + * because the architecture does not guarantee that GPRs will retain + * their full 64-bit values across a 32-bit mode switch. + */ + pushq %rbp + pushq %rbx + pushq %rsi + + /* + * Push the 64-bit address of trampoline_return() onto the new stack. + * It will be used by the trampoline to return to the main code. Due to + * the 32-bit mode switch, it cannot be kept it in a register either. */ leaq trampoline_return(%rip), %rdi + pushq %rdi /* Switch to compatibility mode (CS.L = 0 CS.D = 1) via far return */ pushq $__KERNEL32_CS @@ -471,6 +485,11 @@ SYM_CODE_START(startup_64) pushq %rax lretq trampoline_return: + /* Restore live 64-bit registers */ + popq %rsi + popq %rbx + popq %rbp + /* Restore the stack, the 32-bit trampoline uses its own stack */ leaq rva(boot_stack_end)(%rbx), %rsp @@ -582,7 +601,7 @@ SYM_FUNC_END(.Lrelocated) /* * This is the 32-bit trampoline that will be copied over to low memory. * - * RDI contains the return address (might be above 4G). + * Return address is at the top of the stack (might be above 4G). * ECX contains the base address of the trampoline memory. * Non zero RDX means trampoline needs to enable 5-level paging. */ @@ -592,9 +611,6 @@ SYM_CODE_START(trampoline_32bit_src) movl %eax, %ds movl %eax, %ss - /* Set up new stack */ - leal TRAMPOLINE_32BIT_STACK_END(%ecx), %esp - /* Disable paging */ movl %cr0, %eax btrl $X86_CR0_PG_BIT, %eax @@ -671,7 +687,7 @@ SYM_CODE_END(trampoline_32bit_src) .code64 SYM_FUNC_START_LOCAL_NOALIGN(.Lpaging_enabled) /* Return from the trampoline */ - jmp *%rdi + retq SYM_FUNC_END(.Lpaging_enabled) /* -- 2.39.2