Re: [RFC PATCH v2 3/5] dma-mapping: Decrypt memory on remap

Aneesh Kumar K.V
2026-04-13T06:23:46Z

Mostafa Saleh <smostafa@google.com> writes:

> In case memory needs to be remapped on systems with
> force_dma_unencrypted(), where this memory is not allocated
> from a restricted-dma pool, this was currently ignored, while only
> setting the decrypted pgprot in the remapped alias.
>
> The memory still needs to be decrypted in that case.
>
> With memory decryption, don't allow highmem allocations, but that
> shouldn't be a problem on such modern systems.
>
> Reported-by: Catalin Marinas <catalin.marinas@arm.com>
> Fixes: f3c962226dbe ("dma-direct: clean up the remapping checks in dma_direct_alloc")
> Signed-off-by: Mostafa Saleh <smostafa@google.com>
> ---
> kernel/dma/direct.c | 16 +++++++++++-----
> 1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> index 1a402bb956d9..a4260689bcc8 100644
> --- a/kernel/dma/direct.c
> +++ b/kernel/dma/direct.c
> @@ -203,6 +203,7 @@ static void *dma_direct_alloc_no_mapping(struct device *dev, size_t size,
> void *dma_direct_alloc(struct device *dev, size_t size,
> dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
> {
> + bool allow_highmem = !force_dma_unencrypted(dev);
> bool remap = false, set_uncached = false;
> struct page *page;
> void *ret;
> @@ -251,7 +252,7 @@ void *dma_direct_alloc(struct device *dev, size_t size,
> return dma_direct_alloc_from_pool(dev, size, dma_handle, gfp);
>
> /* we always manually zero the memory once we are done */
> - page = __dma_direct_alloc_pages(dev, size, gfp & ~__GFP_ZERO, true);
> + page = __dma_direct_alloc_pages(dev, size, gfp & ~__GFP_ZERO, allow_highmem);
> if (!page)
> return NULL;
>
> @@ -265,6 +266,9 @@ void *dma_direct_alloc(struct device *dev, size_t size,
> set_uncached = false;
> }
>
> + if (dma_set_decrypted(dev, page_address(page), size))
> + goto out_leak_pages;
> +
> if (remap) {
> pgprot_t prot = dma_pgprot(dev, PAGE_KERNEL, attrs);
>
> @@ -278,11 +282,9 @@ void *dma_direct_alloc(struct device *dev, size_t size,
> ret = dma_common_contiguous_remap(page, size, prot,
> __builtin_return_address(0));
> if (!ret)
> - goto out_free_pages;
> + goto out_encrypt_pages;
> } else {
> ret = page_address(page);
> - if (dma_set_decrypted(dev, ret, size))
> - goto out_leak_pages;
> }
>
> memset(ret, 0, size);
> @@ -300,7 +302,6 @@ void *dma_direct_alloc(struct device *dev, size_t size,
> out_encrypt_pages:
> if (dma_set_encrypted(dev, page_address(page), size))
> return NULL;
> -out_free_pages:
> __dma_direct_free_pages(dev, page, size);
> return NULL;
> out_leak_pages:
> @@ -339,7 +340,12 @@ void dma_direct_free(struct device *dev, size_t size,
> return;
>
> if (is_vmalloc_addr(cpu_addr)) {
> + void *vaddr = page_address(dma_direct_to_page(dev, dma_addr));
> +
> vunmap(cpu_addr);
> +
> + if (dma_set_encrypted(dev, vaddr, size))
> + return;

Right now, a remap is required under two conditions:

1. HighMem — I assume we are avoiding this for devices that require memory decryption.
2. The device is not DMA-coherent.

Can we assume that condition (2) will also not be supported alongside
memory encryption/decryption? That would allow us to simplify all of
this. We would then only need to carry the patch that disables HighMem
for devices requiring unencrypted DMA buffers.

I did post a patch along similar lines some time back. There is also the
challenge of presenting a vmap address as decrypted on ARM.
https://lore.kernel.org/all/20260102155037.2551524-1-aneesh.kumar@kernel.org

> } else {
> if (IS_ENABLED(CONFIG_ARCH_HAS_DMA_CLEAR_UNCACHED))
> arch_dma_clear_uncached(cpu_addr, size);
> --
> 2.53.0.1185.g05d4b7b318-goog