From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 67911440A00; Thu, 20 Aug 2026 12:29:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787228977; cv=none; b=u9Bhd5isydWCrcoYNrplSk5UxvXmBOFn0DsYKIqtaBwWV457tccgYuUQSdGnOp18spEImpIgCgcbzbVGGNZF0+QiXz2qbkPrsx/AorLxnpowHlYQu1vDklDe2rqKB4Si5CM2cWKCEe3RaqnwjXA/ogw9ZfdeaeWCmOIPxDnGue0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787228977; c=relaxed/simple; bh=S9xYEc9QWJLZ9+RIlF/8tA2j7yd0aorjeIQJnXLSf1Y=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=N5a3EonAmBINF0VCM+VwnHOK06rz6FS5OdTo70eLEJSZZDCvocQjqbxzk9t4UH9JEVmA6/LH979Tps3ZGzhpwGF9KRR1V2CefqoXRrea10K99Z/4RgEPBk2ek/IMS592vsvyxWD7cffqLFxPRL282f6a+I4DTn6q6rGjYxyLna4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=LG4vJuZd; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="LG4vJuZd" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 123C51F000E9; Thu, 20 Aug 2026 12:29:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1787228976; bh=fDbCR6e6GGxWccQ5R9SSxtDkxyXxcSTxE7SQ3aY7yfo=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=LG4vJuZdQo+bj+td5H2YT/W/PngjBWUumg8xnHXg9BxzUsXbaUnCaciWgvUDRghV9 RIfhqs38Tx5dNa5TBXyEr6CAUb1zMvwYrf3uwH6Q54TIC37tFdRrr7TZJz+8i/sHtf 12nVFDV8cRGNwC/gTIbDIXkbZoJZ0nv4UI5q3xVNV2W3mdfUrfl9u3UqMyHuEsPziZ SatEkDTmM2fQPbGR4hCw4TEGredM6nwF69aXSrj6F1IDpptwyLjcHMmj1QFMRfKJNu DFj//TDzMMU/RRZXjidu8UHBW9g8oj+5Amlh50n9D5meGx7T4XKGbJsHum7EKe7JK3 tnf/Y8gja+RjQ== Received: from sofa.misterjones.org ([185.219.108.64] helo=lobster-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wx1tl-0000000HHzy-3P2J; Thu, 20 Aug 2026 12:29:33 +0000 Date: Thu, 20 Aug 2026 13:32:05 +0100 Message-ID: <87wltlnfay.wl-maz@kernel.org> From: Marc Zyngier To: Steven Price Cc: Christian =?UTF-8?B?S8O2bmln?= , Sumit Semwal , Thomas Gleixner , "T.J. Mercier" , Benjamin Gaignard , Brian Starkey , John Stultz , dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, Jason Gunthorpe , Jiri Pirko , Marek Szyprowski , Suzuki K Poulose Subject: Re: [PATCH 1/2] irqchip/gic-v3-its: Zero shared pages after conversion In-Reply-To: <20260820105026.53208-2-steven.price@arm.com> References: <20260820105026.53208-1-steven.price@arm.com> <20260820105026.53208-2-steven.price@arm.com> 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/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: steven.price@arm.com, christian.koenig@amd.com, sumit.semwal@linaro.org, tglx@kernel.org, tjmercier@google.com, benjamin.gaignard@collabora.com, Brian.Starkey@arm.com, jstultz@google.com, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, jgg@ziepe.ca, jiri@resnulli.us, m.szyprowski@samsung.com, suzuki.poulose@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Thu, 20 Aug 2026 11:50:24 +0100, Steven Price wrote: > > its_alloc_pages_node() passes __GFP_ZERO to the page allocator before > calling set_memory_decrypted(). This assumes that converting a page from > private to shared preserves its contents. > > For Arm CCA with MEC (Memory Encryption Contexts) the key used to access > the page will change, and so by default the visible data will change. > The host could ensure that it zeros the page, but rather than relying on > the host's behaviour it's best if the guest simply zeros after the > decryption rather than before. Specifically in this case the ITS tables > are required to be zeroed. What are the guarantees that we want to enforce post decryption? My recollection is that the RME firmware cleans the caches to the PoPA, making the data immediately visible to the hypervisor. Obviously, this isn't the case anymore, since the zeroing comes after that, and I don't see any CMO enforcing this. I'm concerned that this relies on undocumented behaviours that may hold today on some undisclosed combinations of HW and hypervisors, but that are not guaranteed at all. set_memory_decrypted() doesn't really say anything, and I have the feeling that we may want some hypervisor specific hook to perform the correct CMO magic. I don't think this is required right now, but I'm not excluding anything! > > Mask out __GFP_ZERO from the allocation request, and do the zeroing as a > separate step after decryption. > > Fixes: b08e2f42e86b ("irqchip/gic-v3-its: Share ITS tables with a non-trusted hypervisor") > Signed-off-by: Steven Price > --- > drivers/irqchip/irq-gic-v3-its.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c > index 6f5811aae59c..c954bbe9f4db 100644 > --- a/drivers/irqchip/irq-gic-v3-its.c > +++ b/drivers/irqchip/irq-gic-v3-its.c > @@ -213,10 +213,12 @@ static gfp_t gfp_flags_quirk; > static struct page *its_alloc_pages_node(int node, gfp_t gfp, > unsigned int order) > { > + bool want_zero = gfp & __GFP_ZERO; > struct page *page; > int ret = 0; > > - page = alloc_pages_node(node, gfp | gfp_flags_quirk, order); > + page = alloc_pages_node(node, (gfp & ~__GFP_ZERO) | gfp_flags_quirk, > + order); > > if (!page) > return NULL; > @@ -231,6 +233,9 @@ static struct page *its_alloc_pages_node(int node, gfp_t gfp, > if (ret) > return NULL; > > + if (want_zero) > + clear_pages(page_address(page), 1 << order); > + nit: please use BIT(order), which matches the type required for clear_pages(). But I'd really like some discussion about the CMO side of things. M. -- Jazz isn't dead. It just smells funny.