From mboxrd@z Thu Jan 1 00:00:00 1970 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 4195BC25B10 for ; Mon, 13 May 2024 13:56:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=DYTZa/K+faxcjVIko5GTmR+8sENxotdZjFMFWOr1IU4=; b=OQNfurHTBZdwPw A8HS6mHwiAG0u5VmyrELGPC7c+MqX7kum7AJ1GwbZAYKrEDq62zdfu9pOmQbMd0Q/df1nsVHABmd2 InxSTVgYRmDZxv5y+dG/4TWQ/sbuVBsQq/aTyvf3MamZtrGYhynXiPMzlZiH3wA1mdhmcsD+BTn6r qPFfKmvRlLmpjP3tFcEooFpnd/BSXFFbkLgznhmyC8DmNqJNaVF0/iSSRhKtQ7aYy2j7PahNAQQhU C3X84JKZiRIFXy40P+B7whtEep6zKbjR9zRlBwS543PGCdMmqJoRpmiUxxdEjkYDNsu1CNpXtyZ2+ PuCVWSSkGgEYbD+LEszQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1s6W9h-0000000D5NH-0f7m; Mon, 13 May 2024 13:55:53 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1s6W9e-0000000D5MT-0MZB for linux-arm-kernel@lists.infradead.org; Mon, 13 May 2024 13:55:51 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 4CFC160DDF; Mon, 13 May 2024 13:55:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5A774C113CC; Mon, 13 May 2024 13:55:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1715608548; bh=+zJygHwJDYYbEHrrcyWnil8v90ICcXTefv5dJxPZ8lI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=E21Yv4CjfRNH9NPlgkc8u7W1/WiUPP+/YhrSUmG92G6vgADSfsWECEKcpOMhyEfG/ RbpGvEBPmK4qhlTtTRp18c/c2Jrxg3/HEXhg+XtU8DkruSan+t5ct+a5eT+JVNHYwX zdSNb5naXaJBpBrUHam4L8u7AWMjMWLYLSJgzmwDspv4ZIpr9G3mSLUAyB8hdyj1P0 cnBcw+sEKShIvp4QsrAxO4WElLFWhUjjALm8Y4SHCqARkdqLGA93RFa6KbJLaCKGBD bz814/nJPG09eFFTbVOMRuUZDnPshBl60b1iZD/ykTEnQTXxJMI5FwPdNoeDAmF+b1 iDbl+22GqOMHA== Date: Mon, 13 May 2024 14:55:42 +0100 From: Will Deacon To: =?iso-8859-1?Q?Pierre-Cl=E9ment?= Tosi Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, Marc Zyngier , Oliver Upton , Suzuki K Poulose , Vincent Donnefort Subject: Re: [PATCH v3 01/12] KVM: arm64: Fix clobbered ELR in sync abort/SError Message-ID: <20240513135542.GA28749@willie-the-truck> References: <20240510112645.3625702-1-ptosi@google.com> <20240510112645.3625702-2-ptosi@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20240510112645.3625702-2-ptosi@google.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240513_065550_240768_AC9AE9C8 X-CRM114-Status: GOOD ( 20.87 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, May 10, 2024 at 12:26:30PM +0100, Pierre-Cl=E9ment Tosi wrote: > When the hypervisor receives a SError or synchronous exception (EL2h) > while running with the __kvm_hyp_vector and if ELR_EL2 doesn't point to > an extable entry, it panics indirectly by overwriting ELR with the > address of a panic handler in order for the asm routine it returns to to > ERET into the handler. > = > However, this clobbers ELR_EL2 for the handler itself. As a result, > hyp_panic(), when retrieving what it believes to be the PC where the > exception happened, actually ends up reading the address of the panic > handler that called it! This results in an erroneous and confusing panic > message where the source of any synchronous exception (e.g. BUG() or > kCFI) appears to be __guest_exit_panic, making it hard to locate the > actual BRK instruction. > = > Therefore, store the original ELR_EL2 in the per-CPU kvm_hyp_ctxt and > point the sysreg to a routine that first restores it to its previous > value before running __guest_exit_panic. > = > Fixes: 7db21530479f ("KVM: arm64: Restore hyp when panicking in guest con= text") > Signed-off-by: Pierre-Cl=E9ment Tosi > --- > arch/arm64/kernel/asm-offsets.c | 1 + > arch/arm64/kvm/hyp/entry.S | 9 +++++++++ > arch/arm64/kvm/hyp/include/hyp/switch.h | 5 +++-- > 3 files changed, 13 insertions(+), 2 deletions(-) > = > diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offs= ets.c > index 81496083c041..27de1dddb0ab 100644 > --- a/arch/arm64/kernel/asm-offsets.c > +++ b/arch/arm64/kernel/asm-offsets.c > @@ -128,6 +128,7 @@ int main(void) > DEFINE(VCPU_FAULT_DISR, offsetof(struct kvm_vcpu, arch.fault.disr_el1)= ); > DEFINE(VCPU_HCR_EL2, offsetof(struct kvm_vcpu, arch.hcr_el2)); > DEFINE(CPU_USER_PT_REGS, offsetof(struct kvm_cpu_context, regs)); > + DEFINE(CPU_ELR_EL2, offsetof(struct kvm_cpu_context, sys_regs[ELR_EL2= ])); > DEFINE(CPU_RGSR_EL1, offsetof(struct kvm_cpu_context, sys_regs[RGSR_E= L1])); > DEFINE(CPU_GCR_EL1, offsetof(struct kvm_cpu_context, sys_regs[GCR_EL1= ])); > DEFINE(CPU_APIAKEYLO_EL1, offsetof(struct kvm_cpu_context, sys_regs[AP= IAKEYLO_EL1])); > diff --git a/arch/arm64/kvm/hyp/entry.S b/arch/arm64/kvm/hyp/entry.S > index f3aa7738b477..bcaaf1a11b4e 100644 > --- a/arch/arm64/kvm/hyp/entry.S > +++ b/arch/arm64/kvm/hyp/entry.S > @@ -83,6 +83,15 @@ alternative_else_nop_endif > eret > sb > = > +SYM_INNER_LABEL(__guest_exit_restore_elr_and_panic, SYM_L_GLOBAL) > + // x0-x29,lr: hyp regs > + > + stp x0, x1, [sp, #-16]! > + adr_this_cpu x0, kvm_hyp_ctxt, x1 > + ldr x0, [x0, #CPU_ELR_EL2] > + msr elr_el2, x0 > + ldp x0, x1, [sp], #16 Why do you have to preserve x0 and x1 here? afaict, we fall into __guest_exit_panic(), which clobbers them both immediately because it's going to pull them off the stack (they get saved _very_ early during exception entry). Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel