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 BE76D106B50C for ; Wed, 25 Mar 2026 12:12:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=aDmI5FPFW31ONEJWUclmhyA8YkzFfd/2GSRQYjDk150=; b=Sk50ylbnE0kyEY2skdi4b2Ne3J tAnwzAOjPoFuFErb+s45kI1IuQ3Mk7i0uitrJV3LEy1DiGXf6UZs+655otGc9h99JGTDUJB8HYdNp J+12bynTMp71IZml6rjytpu7V3ef2gk5KeV3GowH2aRadQ+fRyO4FCySXHqJHD7DK6D6sK9Adw7SQ wzHdh6DYIayqhNrwXuQPZQQdBBKJGQkaYrTantwEqPI4lRC9p3TtF5vFhEkw31hfKWRLYs/8WS51y TPtE7acpZ2BS4zE6buLLoTkTI6yGq7wBK56RTuhe1W0CwxFHapIoZjQX0uu61gzDnwCUmIV8PRnnK lwGBM7MA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1w5N63-00000003M0S-2KGQ; Wed, 25 Mar 2026 12:12:27 +0000 Received: from sea.source.kernel.org ([172.234.252.31]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1w5N61-00000003M08-1dLW for linux-arm-kernel@lists.infradead.org; Wed, 25 Mar 2026 12:12:26 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id BD4BF43814; Wed, 25 Mar 2026 12:12:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0081BC4CEF7; Wed, 25 Mar 2026 12:12:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774440744; bh=sYgpxGo9jlZL6+m+mVfdS9j37scj2obQEFdntrcJch8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=I3O/muHj/Xwt3972sYtMJ7nPAOkaplNPL/3Wt7AwEbjEr04PKKok1RbUHC2prnPFa l+nMKtH/HqKnfQoXRmM3Ky84bbRoyA23j+R85bm8l/9imKsm5qtVGlxkXvYlWzIKWI 4iXtzknXFu6DzN6tOqIWjCkYs6vqNN5kjg6/qIO1oTspSHpgRs9KdRiTsjiyOOgVoi aq9FQMPbKrxF1nYuJvQzhDXBVOJtrDCStpOdkqrzVkbEtVPv1KJe5+cQuf68BFQQXq EHll6LfHnlxLjeS0Yyjn+ho2SmkMq/CdYhOcop/R95aG4WtBm4X/Pwe3nnIRyIHxI0 PhvkPvp2nQtTQ== Date: Wed, 25 Mar 2026 12:12:18 +0000 From: Will Deacon To: Marc Zyngier Cc: Sebastian Ene , Vincent Donnefort , kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, android-kvm@google.com, catalin.marinas@arm.com, joey.gouly@arm.com, mark.rutland@arm.com, oupton@kernel.org, suzuki.poulose@arm.com, tabba@google.com, yuzenghui@huawei.com Subject: Re: [PATCH v2] KVM: arm64: Prevent the host from using an smc with imm16 != 0 Message-ID: References: <20260325113138.4171430-1-sebastianene@google.com> <86ldfg3ze2.wl-maz@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86ldfg3ze2.wl-maz@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260325_051225_491602_CDAAA524 X-CRM114-Status: GOOD ( 31.21 ) 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 On Wed, Mar 25, 2026 at 11:46:29AM +0000, Marc Zyngier wrote: > On Wed, 25 Mar 2026 11:35:18 +0000, > Vincent Donnefort wrote: > > > > On Wed, Mar 25, 2026 at 11:31:38AM +0000, Sebastian Ene wrote: > > > The ARM Service Calling Convention (SMCCC) specifies that the function > > > identifier and parameters should be passed in registers, leaving the > > > 16-bit immediate field of the SMC instruction un-handled. > > > Currently, our pKVM handler ignores the immediate value, which could lead > > > to non-compliant software relying on implementation-defined behavior. > > > Enforce the host kernel running under pKVM to use an immediate value > > > of 0 by decoding the ISS from the ESR_EL2 and return a not supported > > > error code back to the caller. > > > > > > Signed-off-by: Sebastian Ene > > > --- > > > v1 -> v2: > > > > > > - Dropped injecting an UNDEF and return an error instead > > > (SMCCC_RET_NOT_SUPPORTED) > > > - Used the mask ESR_ELx_xVC_IMM_MASK instead of masking with U16_MAX > > > - Updated the title of the commit message from: > > > "[PATCH] KVM: arm64: Inject UNDEF when host is executing an > > > smc with imm16 != 0 > > > > > --- > > > arch/arm64/kvm/hyp/nvhe/hyp-main.c | 6 ++++++ > > > 1 file changed, 6 insertions(+) > > > > > > diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c > > > index e7790097db93..4ffe30fd8707 100644 > > > --- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c > > > +++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c > > > @@ -762,6 +762,12 @@ void handle_trap(struct kvm_cpu_context *host_ctxt) > > > handle_host_hcall(host_ctxt); > > > break; > > > case ESR_ELx_EC_SMC64: > > > + if (ESR_ELx_xVC_IMM_MASK & esr) { > > > + cpu_reg(host_ctxt, 0) = SMCCC_RET_NOT_SUPPORTED; > > > + kvm_skip_host_instr(); > > > + break; > > > + } > > > + > > > > I wonder if it isn't better to move that into handle_host_smc() as this is part > > of how we handle the SMC after all? (and it calls that kvm_skip_host_instr() > > already) > > Yes, that'd be vastly better. > > It also begs the question: if you don't want to handle SMCs with a > non-zero immediate, why is it OK to do it for HVCs? I suppose the difference is that the HVC API is a private interface between EL2 and the host. As it stands, EL2 ignores the immediate but we don't have a way to know how EL3 responds to the immediate for an SMC. When proxying an SMC from the host, EL2 therefore has three choices: 1. Ignore the immediate from the host and always use zero when talking to EL3. That's the current behaviour, but it could theoretically lead to problems if EL3 is using the immediate for something. 2. Propagate the immediate from the host. That should work, but it's a bit involved. 3. Reject non-zero immediates (this patch). Will