From patchwork Mon Feb 26 10:05:57 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marc Zyngier X-Patchwork-Id: 13571826 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 BE37AC48BF6 for ; Mon, 26 Feb 2024 10:09:18 +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:MIME-Version:References:In-Reply-To: Message-Id:Date:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=akHW3iCffLEuiNEd/3z5dqGDLk9BOnR0I6xNgAeoZnI=; b=YyLjpMFl2FyUWN Urq9pacsuZyoxfKh1V73a0YUvRW1CnNokO32j1Bp8RvItSzrwNDCGYh8zMW6q2hTqXDqpqNseyGE3 1LP8iv74N9vvDUH4i5huQ2c5HSWpLrh3D1GU3IK1DBHP3kj8P8s/pBBhxSrbGNyUg4bTZB6wyBEDF gzI3VaqQwGXn4PQ/Qw+XaPZrPzwrUU9B05/W1K+OchORy9yhMIdqAKbYchg54hq9ZIsjgSF5qN1Nl E2bsXHaYmYxC0uZ9SXWV+vEq3DUMaL/e4p6uRvMceUpy2hV0pO0FZMH8pBELAxXxWr4DefyuBqb7a 5UOTpm8JeoyKGO3t+0aQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1reXuc-0000000HXyX-15U1; Mon, 26 Feb 2024 10:08:42 +0000 Received: from desiato.infradead.org ([2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1reXu4-0000000HXjn-3zpN for linux-arm-kernel@bombadil.infradead.org; Mon, 26 Feb 2024 10:08:26 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=Content-Transfer-Encoding:MIME-Version :References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To: Content-Type:Content-ID:Content-Description; bh=u4PWcoVB6JXCBVIY3ZF4FGvlzfIawLvdEb84e7JmoRc=; b=XZn8Q1X76gUA7dZfGPqXQk+9Fm zfD2NWFuMkUXaKrMGr/P9uGGWEtmUsD6qu8Dv7x6qC8ZNtTHYdhp2Q1u897x4a4U7uGTrJG31EM1R 6L7zjX5Fs9NJ6vldKlo+uxipWs3gem+CPQkdOYAW2fA0mBsKHR8ZFvY4Kn8qTXJj5J5kBhDsdBouR wOPFjFfRa+/z55pUG5CeYKjFEd4H3mFJ37yHzev75dFYSz1SuTOKHy3RtQVbh3e5MSQvgbx49uKh/ +6tVZnZ0+Xw2pwEYQ9d19T2emq2mS+jJ1eJwNB4g7/vM0rymq9Nt56obOb7mnNT2Rb7IL8vjBEcum DaH7lG9w==; Received: from dfw.source.kernel.org ([139.178.84.217]) by desiato.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1reXtw-00000001769-1GLU for linux-arm-kernel@lists.infradead.org; Mon, 26 Feb 2024 10:08:07 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 4317560FD4; Mon, 26 Feb 2024 10:07:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1684EC433C7; Mon, 26 Feb 2024 10:07:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1708942059; bh=Alk8DkWcPcruQ5um5KDrpSCEo4m97neZZIMYfFIrE54=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=nf/uT4p9ryqSnx1s8LF/2/lSMt+CdFhw1PXcwaEpe1ezcf/aWMGzrxkaRPwf/HvXb Y9jh+2HmImSqKyWM1RQCTBnMkCFRLguLdKOUsCI3RSyng9t9p2N9581tlxEo2h3ltZ FYERoGSdELZGKSzV08WoDwjmh9hTRJFFbVgVPKhiIrIUFkC0m8eDfv2Hsf+Va+5WGI fRWLBD47DUveJDny8EqjTApCJeHcGEANbR5bTGAwvD6ypWxeMlicdhED6O9tx/DaOc HD6WFiHs3NEFJlIRs1VwB8vPizduPYkl+HgALYYXYGrwVFX4ph1j24IxUljgtrmyvC nhBTVe/TRcupw== Received: from sofa.misterjones.org ([185.219.108.64] helo=valley-girl.lan) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1reXtY-006nQ5-VC; Mon, 26 Feb 2024 10:07:37 +0000 From: Marc Zyngier To: kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org Cc: James Morse , Suzuki K Poulose , Oliver Upton , Zenghui Yu , Joey Gouly , Will Deacon , Catalin Marinas Subject: [PATCH v2 09/13] KVM: arm64: nv: Reinject PAC exceptions caused by HCR_EL2.API==0 Date: Mon, 26 Feb 2024 10:05:57 +0000 Message-Id: <20240226100601.2379693-10-maz@kernel.org> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240226100601.2379693-1-maz@kernel.org> References: <20240226100601.2379693-1-maz@kernel.org> MIME-Version: 1.0 X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, james.morse@arm.com, suzuki.poulose@arm.com, oliver.upton@linux.dev, yuzenghui@huawei.com, joey.gouly@arm.com, will@kernel.org, catalin.marinas@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240226_100800_730615_456491FA X-CRM114-Status: GOOD ( 17.27 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org In order for a L1 hypervisor to correctly handle PAuth instructions, it must observe traps caused by a L1 PAuth instruction when HCR_EL2.API==0. Since we already handle the case for API==1 as a fixup, only the exception injection case needs to be handled. Rework the kvm_handle_ptrauth() callback to reinject the trap in this case. Note that APK==0 is already handled by the exising triage_sysreg_trap() helper. Signed-off-by: Marc Zyngier --- arch/arm64/kvm/handle_exit.c | 28 +++++++++++++++++++++++++--- 1 file changed, 25 insertions(+), 3 deletions(-) diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c index 6a88ec024e2f..1ba2f788b2c3 100644 --- a/arch/arm64/kvm/handle_exit.c +++ b/arch/arm64/kvm/handle_exit.c @@ -214,12 +214,34 @@ static int handle_sve(struct kvm_vcpu *vcpu) } /* - * Guest usage of a ptrauth instruction (which the guest EL1 did not turn into - * a NOP). If we get here, it is that we didn't fixup ptrauth on exit, and all - * that we can do is give the guest an UNDEF. + * Two possibilities to handle a trapping ptrauth instruction: + * + * - Guest usage of a ptrauth instruction (which the guest EL1 did not + * turn into a NOP). If we get here, it is that we didn't fixup + * ptrauth on exit, and all that we can do is give the guest an + * UNDEF (as the guest isn't supposed to use ptrauth without being + * told it could). + * + * - Running an L2 NV guest while L1 has left HCR_EL2.API==0, and for + * which we reinject the exception into L1. API==1 is handled as a + * fixup so the only way to get here is when API==0. + * + * Anything else is an emulation bug (hence the WARN_ON + UNDEF). */ static int kvm_handle_ptrauth(struct kvm_vcpu *vcpu) { + if (!vcpu_has_ptrauth(vcpu)) { + kvm_inject_undefined(vcpu); + return 1; + } + + if (vcpu_has_nv(vcpu) && !is_hyp_ctxt(vcpu)) { + kvm_inject_nested_sync(vcpu, kvm_vcpu_get_esr(vcpu)); + return 1; + } + + /* Really shouldn't be here! */ + WARN_ON_ONCE(1); kvm_inject_undefined(vcpu); return 1; }