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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4040ECD4F49 for ; Fri, 22 Sep 2023 10:08:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233203AbjIVKIs (ORCPT ); Fri, 22 Sep 2023 06:08:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49248 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231180AbjIVKIq (ORCPT ); Fri, 22 Sep 2023 06:08:46 -0400 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9939A8F; Fri, 22 Sep 2023 03:08:40 -0700 (PDT) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3000CC433C7; Fri, 22 Sep 2023 10:08:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1695377320; bh=+nkvC+9xvHlUAEcQG/DhSghnfCoIhmHjwaRNqhkvr90=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=WkcLbHYK2YYPDXgLxBobTGGK6Ge/SzIV/+LnyJFCU4rKuq+iHSop5ULZ1QD6zSQqg yElFmYJo0xfHcGYHzYgzvnPtyvQjOstO4OhyS6ef92yPvTCIxTJIYPRIZx4ZYuJShG 4sWEMM3/1DoDVTMVCSE4e5rXua/8HErG6SacmSaN0xkP9poiuxH7q7QNvpxs6vk1YS px4fN8+w1AMS11V4f6v/1Y6H5peQSAIcGEc7I7ylxuOFb0pNZDXetN3nLVh2G17xVP cAQlOleNe7sBz+oBvknyUA9hf2Bw6msBbGGnIcVWgSfBIxYmZPjfq4adN7nH5HTK1v mil8QBAV3Dbug== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1qjd5R-00FHZ0-AF; Fri, 22 Sep 2023 11:08:37 +0100 Date: Fri, 22 Sep 2023 11:08:30 +0100 Message-ID: <86y1gyo6zl.wl-maz@kernel.org> From: Marc Zyngier To: "Jitindar Singh, Suraj" Cc: "vdonnefort@google.com" , "philmd@linaro.org" , "james.morse@arm.com" , "suzuki.poulose@arm.com" , "oliver.upton@linux.dev" , "qperret@google.com" , "kvmarm@lists.linux.dev" , "catalin.marinas@arm.com" , "linux-arm-kernel@lists.infradead.org" , "kvmarm@lists.cs.columbia.edu" , "stable@vger.kernel.org" , "will@kernel.org" , "linux-kernel@vger.kernel.org" , "alexandru.elisei@arm.com" Subject: Re: [PATCH stable 6.1.y 1/2] KVM: arm64: Prevent the donation of no-map pages In-Reply-To: References: <20230920192729.694309-1-surajjs@amazon.com> <878r903snv.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/29.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: surajjs@amazon.com, vdonnefort@google.com, philmd@linaro.org, james.morse@arm.com, suzuki.poulose@arm.com, oliver.upton@linux.dev, qperret@google.com, kvmarm@lists.linux.dev, catalin.marinas@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, stable@vger.kernel.org, will@kernel.org, linux-kernel@vger.kernel.org, alexandru.elisei@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 21 Sep 2023 23:22:54 +0100, "Jitindar Singh, Suraj" wrote: >=20 > On Thu, 2023-09-21 at 08:13 +0100, Marc Zyngier wrote: > > On Wed, 20 Sep 2023 20:27:28 +0100, > > Suraj Jitindar Singh wrote: > > >=20 > > > From: Quentin Perret > > >=20 > > > commit 43c1ff8b75011bc3e3e923adf31ba815864a2494 upstream. > > >=20 > > > Memory regions marked as "no-map" in the host device-tree routinely > > > include TrustZone carev-outs and DMA pools. Although donating such > > > pages > > > to the hypervisor may not breach confidentiality, it could be used > > > to > > > corrupt its state in uncontrollable ways. To prevent this, let's > > > block > > > host-initiated memory transitions targeting "no-map" pages > > > altogether in > > > nVHE protected mode as there should be no valid reason to do this > > > in > > > current operation. > > >=20 > > > Thankfully, the pKVM EL2 hypervisor has a full copy of the host's > > > list > > > of memblock regions, so we can easily check for the presence of the > > > MEMBLOCK_NOMAP flag on a region containing pages being donated from > > > the > > > host. > > >=20 > > > Reviewed-by: Philippe Mathieu-Daud=C3=A9 > > > Tested-by: Vincent Donnefort > > > Signed-off-by: Quentin Perret > > > Signed-off-by: Will Deacon > > > Signed-off-by: Marc Zyngier > > > Link: > > > https://lore.kernel.org/r/20221110190259.26861-8-will@kernel.org > > > [ bp: clean ] > >=20 > > What is this? >=20 > Noting any details about the backport. In this case it was a clean > backport. I don't think this has anything to do here. If you want to add a note indicating what was changed in the patch, make it *extremely* visible in the commit message, and not hidden as some obscure form of metadata. >=20 > >=20 > > > Signed-off-by: Suraj Jitindar Singh > >=20 > > What is the rationale for backporting this? It wasn't tagged as Cc: > > to > > stable for a reason: pKVM isn't functional upstream, and won't be for > > the next couple of cycles *at least*. > >=20 > > So at it stands, I'm against such a backport. > >=20 >=20 > The 2 patches were backported to address CVE-2023-21264. > This one provides context for the proceeding patch. I care about CVEs as much as I care about holes in my socks (i.e. very little). If there is a concern, it should be brought up on the list as a discussion, and not as a consequence of some script kiddie automatically generating CVEs. > I wasn't aware that it's non functional. Does this mean that the code > won't be compiled or just that it can't actually be run currently from > the upstream codebase? This code is inactive unless you pass the correct option on the command line, and as it is brings zero benefit over standard KVM. The only place this matters is in the Android kernel, as it has full support for pKVM, and has the fix already. We carry it upstream at a courtesy to the pKVM developers, but that's about it. > I guess I'm trying to understand if the conditions of the CVE are a > real concern even if it isn't technically functional. This CVE is a waste of precious bytes, and I have no interest in seeing this backported. Thanks, M. --=20 Without deviation from the norm, progress is not possible.