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

[Mostafa Saleh]

On Mon, Apr 13, 2026 at 11:53:39AM +0530, Aneesh Kumar K.V wrote:
> Mostafa Saleh <smostafa@xxxxxxxxxx> 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@xxxxxxx>
> > Fixes: f3c962226dbe ("dma-direct: clean up the remapping checks in dma_direct_alloc")
> > Signed-off-by: Mostafa Saleh <smostafa@xxxxxxxxxx>
> > ---
> >  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@xxxxxxxxxx

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