From: Mike Rapoport <rppt@kernel.org>
To: Shanker Donthineni <sdonthineni@nvidia.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Steven Price <steven.price@arm.com>,
linux-arm-kernel@lists.infradead.org,
Robin Murphy <robin.murphy@arm.com>,
Gavin Shan <gshan@redhat.com>, Vikram Sethi <vsethi@nvidia.com>,
Jason Sequeira <jsequeira@nvidia.com>,
Dev Jain <dev.jain@arm.com>, David Rientjes <rientjes@google.com>,
linux-kernel@vger.kernel.org, iommu@lists.linux.dev
Subject: Re: [RESEND PATCH 1/2] dma/pool: Use vmap() address for memory encryption helpers on ARM64
Date: Mon, 11 Aug 2025 11:48:29 +0300 [thread overview]
Message-ID: <aJmuXTNUzsq1jKEK@kernel.org> (raw)
In-Reply-To: <20250811005036.714274-2-sdonthineni@nvidia.com>
On Sun, Aug 10, 2025 at 07:50:34PM -0500, Shanker Donthineni wrote:
> In atomic_pool_expand(), set_memory_encrypted()/set_memory_decrypted()
> are currently called with page_to_virt(page). On ARM64 with
> CONFIG_DMA_DIRECT_REMAP=y, the atomic pool is mapped via vmap(), so
> page_to_virt(page) does not reference the actual mapped region.
>
> Using this incorrect address can cause encryption attribute updates to
> be applied to the wrong memory region. On ARM64 systems with memory
> encryption enabled (e.g. CCA), this can lead to data corruption or
> crashes.
>
> Fix this by using the vmap() address ('addr') on ARM64 when invoking
> the memory encryption helpers, while retaining the existing
> page_to_virt(page) usage for other architectures.
>
> Fixes: 76a19940bd62 ("dma-direct: atomic allocations must come from atomic coherent pools")
> Signed-off-by: Shanker Donthineni <sdonthineni@nvidia.com>
> ---
> kernel/dma/pool.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/dma/pool.c b/kernel/dma/pool.c
> index 7b04f7575796b..ba08a301590fd 100644
> --- a/kernel/dma/pool.c
> +++ b/kernel/dma/pool.c
> @@ -81,6 +81,7 @@ static int atomic_pool_expand(struct gen_pool *pool, size_t pool_size,
> {
> unsigned int order;
> struct page *page = NULL;
> + void *vaddr;
> void *addr;
> int ret = -ENOMEM;
>
> @@ -113,8 +114,8 @@ static int atomic_pool_expand(struct gen_pool *pool, size_t pool_size,
> * Memory in the atomic DMA pools must be unencrypted, the pools do not
> * shrink so no re-encryption occurs in dma_direct_free().
> */
> - ret = set_memory_decrypted((unsigned long)page_to_virt(page),
> - 1 << order);
> + vaddr = IS_ENABLED(CONFIG_ARM64) ? addr : page_to_virt(page);
There's address calculation just before this code:
#ifdef CONFIG_DMA_DIRECT_REMAP
addr = dma_common_contiguous_remap(page, pool_size,
pgprot_dmacoherent(PAGE_KERNEL),
__builtin_return_address(0));
if (!addr)
goto free_page;
#else
addr = page_to_virt(page);
#endif
It should be enough to s/page_to_virt(page)/addr in the call to
set_memory_decrypted().
> + ret = set_memory_decrypted((unsigned long)vaddr, 1 << order);
> if (ret)
> goto remove_mapping;
> ret = gen_pool_add_virt(pool, (unsigned long)addr, page_to_phys(page),
> @@ -126,8 +127,7 @@ static int atomic_pool_expand(struct gen_pool *pool, size_t pool_size,
> return 0;
>
> encrypt_mapping:
> - ret = set_memory_encrypted((unsigned long)page_to_virt(page),
> - 1 << order);
> + ret = set_memory_encrypted((unsigned long)vaddr, 1 << order);
> if (WARN_ON_ONCE(ret)) {
> /* Decrypt succeeded but encrypt failed, purposely leak */
> goto out;
> --
> 2.25.1
>
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2025-08-11 9:06 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-11 0:50 [RESEND PATCH 0/2] Add encrypt/decrypt support for vmalloc regions Shanker Donthineni
2025-08-11 0:50 ` [RESEND PATCH 1/2] dma/pool: Use vmap() address for memory encryption helpers on ARM64 Shanker Donthineni
2025-08-11 8:48 ` Mike Rapoport [this message]
2025-08-11 12:09 ` Robin Murphy
2025-08-11 17:26 ` Catalin Marinas
2025-08-11 18:31 ` Shanker Donthineni
2025-08-11 0:50 ` [RESEND PATCH 2/2] arm64: Add encrypt/decrypt support for vmalloc regions Shanker Donthineni
2025-08-11 8:51 ` Mike Rapoport
2025-08-11 13:23 ` Shanker Donthineni
2025-08-11 12:31 ` Robin Murphy
2025-08-11 13:05 ` Shanker Donthineni
2025-08-11 14:17 ` Robin Murphy
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=aJmuXTNUzsq1jKEK@kernel.org \
--to=rppt@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=dev.jain@arm.com \
--cc=gshan@redhat.com \
--cc=iommu@lists.linux.dev \
--cc=jsequeira@nvidia.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=rientjes@google.com \
--cc=robin.murphy@arm.com \
--cc=sdonthineni@nvidia.com \
--cc=steven.price@arm.com \
--cc=suzuki.poulose@arm.com \
--cc=vsethi@nvidia.com \
--cc=will@kernel.org \
/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.