Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp2415865imm; Thu, 7 Jun 2018 10:12:08 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLgG73T+/znmLQ4IUotG/N9jycQnQR03njtNntJejWuJAmMBoRaZIrdoLxlCchIVhhd38Mv X-Received: by 2002:a62:a8e:: with SMTP id 14-v6mr2541726pfk.57.1528391528700; Thu, 07 Jun 2018 10:12:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528391528; cv=none; d=google.com; s=arc-20160816; b=Yk3kqDIG4R+TUwdsG6qWaYRUOkOuSz7w0pwoHq86OBVTSylp7Oumyof1za/vao2bu2 FYI9gRZCd9zQdwte9R/pcGPcfUGRF5pKvtV7CqTJ++8duxx8tAJBHx3L0sK9NdORaQmi 8JYiUC4TOVD/HbQ03DtjVDtGj/RX6GnjK6mNM6IvPdvYF/vUPR7LS9wAVc9C+gY34X9J oiUFEyRDNap31kghkHSiPwCzmmDTX8h0KKvAj0SaIi26d5L9T8l/4tdH3vtU+g5O/NFI k6ogLvWdkRv/MtPiGhxlRuQktV/aL1o5qlSvXdGaKkkTUCj7Elcwbu/YqBMUm1sUi6ET L1Bw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition :arc-authentication-results; bh=kcLJ71eU6t/WvpcPz9vOSwL7pAbElOAsRTKfa0m1n9E=; b=zIuGsWSl1k7vvlTtbc1BoYpS/FzmCRbE/UJ2sxE0yEM6cErmtc73MbPdi/hra5iNAc N5zROrxztVjrTvvGCp01cYElcKvbWZCra2mHWyQTO9msuX73yU93LPu8r3r/jyZeafXC PStfeozgjvhzmMBQGGAX/65HqywquTCTBq418vyxeImaW/XvvWkT4bLUaYv3yTgDQMRh jpAWjqaCQl1eE3ogA3qC0VIHyjqjVFFF2ozu4DdqLg+6KoycpBE/w0PYq/bAVhTXoiRZ qdbAYweRVmJr/VfozSezrB01vax8+6C0DuRV3CWDnH9uberYzLd01R0sGi4O3mwEroqL +tmg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b59-v6si54581576plc.335.2018.06.07.10.11.54; Thu, 07 Jun 2018 10:12:08 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933815AbeFGObr (ORCPT + 99 others); Thu, 7 Jun 2018 10:31:47 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:40255 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933620AbeFGObm (ORCPT ); Thu, 7 Jun 2018 10:31:42 -0400 Received: from [148.252.241.226] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1fQvbh-0005Zm-7U; Thu, 07 Jun 2018 15:09:41 +0100 Received: from ben by deadeye with local (Exim 4.91) (envelope-from ) id 1fQvb5-0002z4-L4; Thu, 07 Jun 2018 15:09:03 +0100 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "Marc Zyngier" , "Catalin Marinas" , "Ard Biesheuvel" Date: Thu, 07 Jun 2018 15:05:21 +0100 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 195/410] arm: KVM: Fix SMCCC handling of unimplemented SMC/HVC calls In-Reply-To: X-SA-Exim-Connect-IP: 148.252.241.226 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.57-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Marc Zyngier commit 20e8175d246e9f9deb377f2784b3e7dfb2ad3e86 upstream. KVM doesn't follow the SMCCC when it comes to unimplemented calls, and inject an UNDEF instead of returning an error. Since firmware calls are now used for security mitigation, they are becoming more common, and the undef is counter productive. Instead, let's follow the SMCCC which states that -1 must be returned to the caller when getting an unknown function number. Tested-by: Ard Biesheuvel Signed-off-by: Marc Zyngier Signed-off-by: Catalin Marinas [bwh: Backported to 3.16: Use vcpu_reg() instead of vcpu_set_reg()] Signed-off-by: Ben Hutchings --- arch/arm/kvm/handle_exit.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) --- a/arch/arm/kvm/handle_exit.c +++ b/arch/arm/kvm/handle_exit.c @@ -45,7 +45,7 @@ static int handle_hvc(struct kvm_vcpu *v ret = kvm_psci_call(vcpu); if (ret < 0) { - kvm_inject_undefined(vcpu); + *vcpu_reg(vcpu, 0) = ~0UL; return 1; } @@ -54,7 +54,16 @@ static int handle_hvc(struct kvm_vcpu *v static int handle_smc(struct kvm_vcpu *vcpu, struct kvm_run *run) { - kvm_inject_undefined(vcpu); + /* + * "If an SMC instruction executed at Non-secure EL1 is + * trapped to EL2 because HCR_EL2.TSC is 1, the exception is a + * Trap exception, not a Secure Monitor Call exception [...]" + * + * We need to advance the PC after the trap, as it would + * otherwise return to the same address... + */ + *vcpu_reg(vcpu, 0) = ~0UL; + kvm_skip_instr(vcpu, kvm_vcpu_trap_il_is32bit(vcpu)); return 1; }