Re: [PATCH] swiotlb: fix a typo
From: Robin Murphy
Date: Wed Aug 31 2022 - 04:02:53 EST
On 2022-08-31 05:22, Chao Gao wrote:
On Tue, Aug 30, 2022 at 10:23:51AM +0100, Robin Murphy wrote:
On 2022-08-26 10:50, Chao Gao wrote:
"overwirte" isn't a word. It should be "overwrite".
Signed-off-by: Chao Gao <chao.gao@xxxxxxxxx>
---
BTW, I am wondering if copying the original buffer to the tlb buffer
unconditionally will leak the original buffer to the VMM, especially
when VMM isn't trusted e.g., by confidential VMs. Would it be better
to zero the tlb buffer for dir == DMA_FROM_DEVICE?
No, at the point of dma_map(), the buffer contents are owned by the caller,
so if parts of that buffer are sensitive and shouldn't be exposed to DMA,
then don't map the whole buffer for DMA. There are more DMA API
implementations than SWIOTLB.
I am not sure if all existing drivers ensure that all buffers allocated
for DMA_FROM_DEVICE are zeroed/poisoned so that they don't have sensitive
data before dma_map(). If that isn't the case, bouncing the original contents
(left by the previous user of the buffer) effectively makes the contents
visible to host/VMM. I am afraid it may be a concern for confidential VMs.
Sure, and in a scheme where pages can be dynamically shared in-place
instead of using SWIOTLB to bounce through a pre-shared buffer, then
those same drivers will still expose the same stale data. Similarly, a
driver could massively over-map with DMA_TO_DEVICE or DMA_BIDIRECTIONAL
and expose all manner of potential secrets that way. It's a concern that
cannot be addressed at the DMA API level. Anyone who wants to completely
trust drivers not to do anything stupid in a confidential compute
scenario is going to have to audit and possibly fix those drivers.
Robin.