Re: [RFC PATCH 1/2] dma-mapping: Avoid double decrypting with DMA_RESTRICTED_POOL

[Aneesh Kumar K . V]

Mostafa Saleh <smostafa@xxxxxxxxxx> writes:

> On Tue, Mar 10, 2026 at 01:55:52PM +0000, Catalin Marinas wrote:
>> On Tue, Mar 10, 2026 at 01:36:08PM +0000, Catalin Marinas wrote:
>> > However, it's unclear to me whether we can get encrypted pages when
>> > is_swiotlb_for_alloc() == false, remap == true and
>> > force_dma_unencrypted() == true in dma_direct_alloc().
>> > dma_set_decrypted() is only called on the !remap path.
>> 
>> Ah, I can see Anneesh trying to address this here:
>> 
>> https://lore.kernel.org/r/yq5abjjl4o0j.fsf@xxxxxxxxxx
>
> I see, thanks for pointing that out, the case Aneesh is fixing is the
> missing decryption in the remap case. However, it’s not clear to me
> how we can get there for CCA, I left a comment on his patch.
>
> I can inline the is_swiotlb_for_alloc() checks outside, but I believe
> adding this in the lowest level is better as indeed the memory is
> decrypted and we don’t have to open code the check in other places are
> dma_direct_alloc_pages()
>

There are a few related changes that I have posted. However, I am
wondering whether it would be simpler to treat the swiotlb pool as
always decrypted. In that case, even when allocating from swiotlb we
would not need to toggle between decrypt/encrypt.

Another reason to treat swiotlb as special is the alignment requirement
when toggling between decrypted and encrypted states.

The patch implementing this approach is here 
https://lore.kernel.org/all/20260309102625.2315725-2-aneesh.kumar@xxxxxxxxxx

With respect to remapping, there are two conditions that can currently
trigger a remap: when the device is non-coherent, or when we receive a
HighMem allocation. Neither of these conditions applies to CCA. We could
potentially enforce the HighMem case by using the following hunk in the
patch:


+
+	if (force_dma_unencrypted(dev))
+		/*
+		 * Unencrypted/shared DMA requires a linear-mapped buffer
+		 * address to look up the PFN and set architecture-required PFN
+		 * attributes. This is not possible with HighMem. Avoid HighMem
+		 * allocation.
+		 */
+		allow_highmem = false;
+
	/* 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;

https://lore.kernel.org/all/20260102155037.2551524-1-aneesh.kumar@xxxxxxxxxx

I haven't got much feedback on that patch yet.

-aneesh