All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Steven Price <steven.price@arm.com>
Cc: "Christian König" <christian.koenig@amd.com>,
	"Sumit Semwal" <sumit.semwal@linaro.org>,
	"Thomas Gleixner" <tglx@kernel.org>,
	"T.J. Mercier" <tjmercier@google.com>,
	"Benjamin Gaignard" <benjamin.gaignard@collabora.com>,
	"Brian Starkey" <Brian.Starkey@arm.com>,
	"John Stultz" <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,
	"Jason Gunthorpe" <jgg@ziepe.ca>, "Jiri Pirko" <jiri@resnulli.us>,
	"Marek Szyprowski" <m.szyprowski@samsung.com>,
	"Suzuki K Poulose" <suzuki.poulose@arm.com>
Subject: Re: [PATCH 1/2] irqchip/gic-v3-its: Zero shared pages after conversion
Date: Thu, 20 Aug 2026 13:32:05 +0100	[thread overview]
Message-ID: <87wltlnfay.wl-maz@kernel.org> (raw)
In-Reply-To: <20260820105026.53208-2-steven.price@arm.com>

On Thu, 20 Aug 2026 11:50:24 +0100,
Steven Price <steven.price@arm.com> 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 <steven.price@arm.com>
> ---
>  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.

  parent reply	other threads:[~2026-08-20 12:29 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-20 10:50 [PATCH 0/2] Clear shared pages after private-to-shared conversion Steven Price
2026-08-20 10:50 ` [PATCH 1/2] irqchip/gic-v3-its: Zero shared pages after conversion Steven Price
2026-08-20 11:08   ` sashiko-bot
2026-08-20 12:32   ` Marc Zyngier [this message]
2026-08-20 12:55     ` Steven Price
2026-08-20 13:27     ` Jason Gunthorpe
2026-08-20 10:50 ` [PATCH 2/2] dma-buf: heaps: Zero system shared heap " Steven Price
2026-08-20 11:02   ` sashiko-bot
2026-08-20 12:20 ` [PATCH 0/2] Clear shared pages after private-to-shared conversion Jason Gunthorpe
2026-08-20 17:34   ` Catalin Marinas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87wltlnfay.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=Brian.Starkey@arm.com \
    --cc=benjamin.gaignard@collabora.com \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jgg@ziepe.ca \
    --cc=jiri@resnulli.us \
    --cc=jstultz@google.com \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=steven.price@arm.com \
    --cc=sumit.semwal@linaro.org \
    --cc=suzuki.poulose@arm.com \
    --cc=tglx@kernel.org \
    --cc=tjmercier@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.