Re: Cache maintenance for non-coherent DMA in arch_sync_dma_for_device()

["Russell King (Oracle)" <linux@armlinux.org.uk>]

On Mon, Jun 06, 2022 at 05:02:50PM +0100, Robin Murphy wrote:
> On 2022-06-06 16:35, Russell King (Oracle) wrote:
> > On Mon, Jun 06, 2022 at 04:21:50PM +0100, Will Deacon wrote:
> > >    (1) What if the DMA transfer doesn't write to every byte in the buffer?
> > 
> > The data that is in RAM gets pulled into the cache and is visible to
> > the CPU - but if DMA doesn't write to every byte in the buffer, isn't
> > that a DMA failure? Should a buffer that suffers DMA failure be passed
> > to the user?
> 
> No, partial DMA writes can sometimes effectively be expected behaviour, see
> the whole SWIOTLB CVE fiasco for the most recent discussion on that:
> 
> https://lore.kernel.org/lkml/1812355.tdWV9SEqCh@natalenko.name/

So we have a CVE'd security hole that was never reported to
maintainers...

> > >    (2) What if the buffer has a virtual alias in userspace (e.g. because
> > >        the kernel has GUP'd the buffer?
> > 
> > Then userspace needs to avoid writing to cachelines that overlap the
> > buffer to avoid destroying the action of the DMA. It shouldn't be doing
> > this anyway (what happens if userspace writes to the same location that
> > is being DMA'd to... who wins?)
> > 
> > However, you're right that invalidating in this case could expose data
> > that userspace shouldn't see, and I'd suggest in this case that DMA
> > buffers should be cleaned in this circumstance before they're exposed
> > to userspace - so userspace only ever gets to see the data that was
> > there at the point they're mapped, or is subsequently written to
> > afterwards by DMA.
> > 
> > I don't think there's anything to be worried about if the invalidation
> > reveals stale data provided the stale data is not older than the data
> > that was there on first mapping.
> 
> Indeed as above that may actually be required. I think cleaning the caches
> on dma_map_* is the most correct thing to do.

It's also the most expensive thing to do as it can push up the slow
on-bus traffic to memory quite a bit, especially when big buffers
are involved.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!