From patchwork Tue Oct 27 21:51:13 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Will Deacon X-Patchwork-Id: 11861947 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 53D37C388F9 for ; Tue, 27 Oct 2020 21:52:06 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id CB0E42222C for ; Tue, 27 Oct 2020 21:52:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="pIEXrqKG"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="wfeRS9GZ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CB0E42222C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:Message-Id:Date: Subject:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=5LTx+iLtdGXMmpSEhZtCF+tYNbCiBLJFO+P2IMhOQ2U=; b=pIEXrqKGpOQTzZpG6kFtjLSfi MvWD/VVfF6flb+eKoEYyAqFVAZmgMFL7x4LpeR9kbWN13xvzf+6LcliV+jjMZIKCr5gXVGs0vYuLr GH/9ZeYzR1ESh2Vcjn3zvQDZ7mtVRoNr7BLb7runmxLm4T5+JoUbc2eo2Uy7Bc4rQV0XKuAq0xSSv z+3A/kUnHeZJOh9FFlrbk+lFDvjToR9VZU/Auq7oRoazwUgBjwo1c6pXkWPqX3icNqFt8TpPFR0Ph wGvZzXZmIW7idhQLpULKfE1Eca9vwVhA+jQCpuyNHrIXZXF03mvPHZQlVky57O/kNBRwLD/Q5eJeN 2L5CT7M5Q==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kXWsS-0002PC-5C; Tue, 27 Oct 2020 21:51:36 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kXWsJ-0002MC-Eu for linux-arm-kernel@lists.infradead.org; Tue, 27 Oct 2020 21:51:28 +0000 Received: from localhost.localdomain (236.31.169.217.in-addr.arpa [217.169.31.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id BC0782222C; Tue, 27 Oct 2020 21:51:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1603835486; bh=Esg3EpfECFhTL7iOJ/NxBoUqAj8LX4q6jNym7Nfr4Mg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=wfeRS9GZUSTaVPY8xaTFMD+96LQjW11D886hCcuB950L8h1O6rLEFyxbmF3qmBMDH fY5AkV1PLoGFmxSL0vYvc/koVgyRjyQ+5H9cKcnW0fMncOmrrFadiXejDkpvPIOMsP ZDHgILA2q3Xn13YJeeBvUV0Nm57BXbl1oyKU12uw= From: Will Deacon To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 1/6] KVM: arm64: Handle Asymmetric AArch32 systems Date: Tue, 27 Oct 2020 21:51:13 +0000 Message-Id: <20201027215118.27003-2-will@kernel.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20201027215118.27003-1-will@kernel.org> References: <20201027215118.27003-1-will@kernel.org> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201027_175127_604129_0844357E X-CRM114-Status: GOOD ( 19.15 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-arch@vger.kernel.org, Marc Zyngier , kernel-team@android.com, Peter Zijlstra , Catalin Marinas , Qais Yousef , Suren Baghdasaryan , James Morse , Greg Kroah-Hartman , Will Deacon , Morten Rasmussen Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org From: Qais Yousef On a system without uniform support for AArch32 at EL0, it is possible for the guest to force run AArch32 at EL0 and potentially cause an illegal exception if running on a core without AArch32. Add an extra check so that if we catch the guest doing that, then we prevent it from running again by resetting vcpu->arch.target and return ARM_EXCEPTION_IL. We try to catch this misbehaviour as early as possible and not rely on an illegal exception occuring to signal the problem. Attempting to run a 32bit app in the guest will produce an error from QEMU if the guest exits while running in AArch32 EL0. Tested on Juno by instrumenting the host to fake asym aarch32 and instrumenting KVM to make the asymmetry visible to the guest. Cc: James Morse Cc: Marc Zyngier Signed-off-by: Qais Yousef [will: Incorporated feedback from Marc] Link: https://lore.kernel.org/r/20201021104611.2744565-2-qais.yousef@arm.com Signed-off-by: Will Deacon --- arch/arm64/kvm/arm.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c index f56122eedffc..a3b32df1afb0 100644 --- a/arch/arm64/kvm/arm.c +++ b/arch/arm64/kvm/arm.c @@ -808,6 +808,25 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu) preempt_enable(); + /* + * The ARMv8 architecture doesn't give the hypervisor + * a mechanism to prevent a guest from dropping to AArch32 EL0 + * if implemented by the CPU. If we spot the guest in such + * state and that we decided it wasn't supposed to do so (like + * with the asymmetric AArch32 case), return to userspace with + * a fatal error. + */ + if (!system_supports_32bit_el0() && vcpu_mode_is_32bit(vcpu)) { + /* + * As we have caught the guest red-handed, decide that + * it isn't fit for purpose anymore by making the vcpu + * invalid. The VMM can try and fix it by issuing a + * KVM_ARM_VCPU_INIT if it really wants to. + */ + vcpu->arch.target = -1; + ret = ARM_EXCEPTION_IL; + } + ret = handle_exit(vcpu, ret); }