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

Mostafa Saleh
2026-04-15T20:31:24Z

On Mon, Apr 13, 2026 at 11:53:39AM +0530, Aneesh Kumar K.V wrote:
> 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

In v3, I prevent highmem allocations for devices that need decryption,
I believe that modern systems with CCA won’t have a problem with that.

With pKVM, it’s possible to have non-coherent devices, but they always
have an IOMMU, so direct-dma is only used for virtualized devices
which are coherent. So, this case is not important.
This is a theoretical bug, I am not sure if any systems are impacted
by, it but I included since Catalin mentioned it on v1 as I am
already including other fixes. But I am happy to drop it or just add
an assertion that it never happens.

Thanks,
Mostafa

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