Re: [PATCH v4 04/13] dma: swiotlb: track pool encryption state and honor DMA_ATTR_CC_SHARED

Mostafa Saleh [off-list ref] writes:

On Tue, May 19, 2026 at 07:30:16PM +0530, Aneesh Kumar K.V wrote:

quoted

Mostafa Saleh [off-list ref] writes:

quoted

quoted

quoted

I am still running more tests, but looking more into it. Setting
force_dma_unencrypted() to true for pKVM guests is wrong, as the
guest shouldn’t try to decrypt arbitrary memory as it can include
sensitive information (for example in case of virtio sub-page
allocation) and should strictly rely on the restricted-dma-pool
for that.

??

Where does force_dma_unencrypted() cause arbitary memory passed into
the DMA API to be decrypted? That should never happen???

Sorry, maybe arbitrary is not the right expression again :)
I mean that, with emulated devices that use the DMA-API under pKVM,
they will map memory coming from other layers (VFS, net) through
vitrio-block, virtio-net... These can be smaller than a page, and

Don't we PAGE_ALIGN these requests?

dma_direct_alloc
	size = PAGE_ALIGN(size);

iommu_dma_alloc_pages
	size_t alloc_size = PAGE_ALIGN(size);

For allocation, yes, and that's fine because we bring memory from
the pool.
But not for mapping, as dma_direct_map_phys(), where the memory is
allocated from the driver or other parts in the kernel and the page
may be shared with other kernel components.

But if we are using restricted-dma-pool, we also have:

mem->force_bounce = true;
mem->for_alloc = true;

So, will we use the swiotlb buffers for mapping and copy only the shared
content into those swiotlb buffers?

-aneesh