All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Steven Price" <steven.price@arm.com>
Cc: dri-devel@lists.freedesktop.org, media-ci@linuxtv.org
Subject: Re: [PATCH 2/2] dma-buf: heaps: Zero system shared heap pages after conversion
Date: Thu, 20 Aug 2026 11:02:38 +0000	[thread overview]
Message-ID: <20260820110238.A40A11F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260820105026.53208-3-steven.price@arm.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] In `system_heap_allocate()`, if `set_memory_decrypted()` fails for an intermediate page, the error handling path attempts to re-encrypt all pages in the buffer, including those that were never decrypted. This can cause state-transition hypercalls to fail on already-encrypted pages, permanently leaking pristine memory.
--

--- Patch [2]: [PATCH 2/2] dma-buf: heaps: Zero system shared heap pages after conversion ---
commit 6c2e28c1010d31d528df19fa7fecbc4eb3e5bcad
Author: Steven Price <steven.price@arm.com>

dma-buf: heaps: Zero system shared heap pages after conversion

This commit modifies the system_cc_shared heap to defer zeroing pages until
after they have been successfully converted from private to shared. This
ensures that the guest clears the memory after decryption, as the decryption
process changes the visible data.

> diff --git a/drivers/dma-buf/heaps/system_heap.c b/drivers/dma-buf/heaps/system_heap.c
> --- a/drivers/dma-buf/heaps/system_heap.c
> +++ b/drivers/dma-buf/heaps/system_heap.c

[ ... ]

> @@ -461,9 +466,12 @@ static struct dma_buf *system_heap_allocate(struct dma_heap *heap,
>  
>  	if (cc_shared_buffer(buffer)) {
>  		for_each_sgtable_sg(table, sg, i) {
> -			ret = system_heap_set_page_decrypted(sg_page(sg));
> +			page = sg_page(sg);
> +			ret = system_heap_set_page_decrypted(page);
>  			if (ret)
>  				goto free_pages;

[Severity: High]
This is a pre-existing issue, but does this error path permanently leak
pages if decryption fails midway?

If system_heap_set_page_decrypted() fails for an intermediate page, the
code jumps to free_pages. The free_pages label iterates over all pages in
the scatterlist unconditionally up to orig_nents:

free_pages:
        for_each_sgtable_sg(table, sg, i) {
                struct page *p = sg_page(sg);
                if (cc_shared_buffer(buffer) &&
                    system_heap_set_page_encrypted(p))
                        continue;
                __free_pages(p, compound_order(p));
        }

For pages later in the scatterlist that were never successfully decrypted,
system_heap_set_page_encrypted() will be called on already-encrypted memory.
If the hypervisor rejects this duplicate encryption request, the pristine
pages skip __free_pages() and are permanently leaked.

Is there a way to track exactly which pages were decrypted so the error path
only attempts to re-encrypt those specific pages?

> +
> +			clear_pages(page_address(page), 1 << compound_order(page));
>  		}
>  	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260820105026.53208-1-steven.price@arm.com?part=2

  reply	other threads:[~2026-08-20 11:02 UTC|newest]

Thread overview: 9+ 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
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 [this message]
2026-08-20 12:20 ` [PATCH 0/2] Clear shared pages after private-to-shared conversion Jason Gunthorpe

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=20260820110238.A40A11F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=media-ci@linuxtv.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=steven.price@arm.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.