On Tue, May 19, 2026 at 07:30:16PM +0530, Aneesh Kumar K.V wrote: > Mostafa Saleh <[email protected]> writes: > > >> > > >> > 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. Thanks, Mostafa > > > using force_dma_unencrypted() will share the whole page. > > And as discussed, that leaks sensitive information to the untrusted > > host. > > I am currently investigating passing iova/phys/size > > to force_dma_unencrypted() and then we can share pages inplace only > > if possible without leaking extra information. > > I am trying to get some performance results first. But the tricky part > > is to get the semantics right, I believe in that case those devices > > shouldn’t use restricted-dma-pools as those should always force > > bouncing. Instead bouncing happens through the default SWIOTLB pool, > > if not possible to decrypt in place. > > > > -aneesh
