linux-kernel - Re: [PATCH][RFC] asm-generic:remove calling flush_write_buffers() in dma_sync_*_for

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 7 Jul 2009 17:30:45 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Ming Lei <tom.leiming@...il.com>
Cc:	"Russell King - ARM Linux" <linux@....linux.org.uk>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Joerg Roedel <joerg.roedel@....com>,
	fujita.tomonori@....ntt.co.jp, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org,
	"linux-arm-kernel" <linux-arm-kernel@...ts.arm.linux.org.uk>
Subject: Re: [PATCH][RFC] asm-generic:remove calling flush_write_buffers() in dma_sync_*_for_cpu

On Tuesday 07 July 2009, Ming Lei wrote:
> > Note that actually you need to do writeback+invalidate in DMA_TO_DEVICE
> 
> IMHO,  writeback in dma map is enough for DMA_TO_DEVICE transfer.

Right. writeback+invalidate would only be needed for bidirectional
transfers but not for DMA_TO_DEVICE.

> > and at least an invalidate in DMA_FROM_DEVICE during dma_map_*.
> > For the unmap, I don't think you ever need to invalidate the cache.
> 
> No,  as Russell said that CPU speculative fetches can make cache "dirty" after
> dma map but before dma is over, then CPU may read inconsistent data
> after DMA_FROM_DEVICE transfer is finished if does not invalidate
> cache in
> dma unmap.

Hmm, I don't think any of the other architectures currently
try to prevent this. Is ARM special in this regard, or does that
mean that the others are broken? What kind of code would cause
a speculative read on a data section that the kernel (by convention)
must not access? Would it be enough to have an rmb() in dma_unmap_*
and dma_sync_*_for_cpu to prevent speculative accesses?

> > If you invalidate only at unmap time for DMA_FROM_DEVICE, a dirty
> > cache line might be accidentally flushed to the buffer after
> > the device has written to it.
> 
> It seems you are reasonable, and we do need to invalidate cache in both dma
> map and dma unmap for DMA_FROM_DEVICE, don't we?

Is it guaranteed that a cache line from a speculative fetch will
never be written back? Otherwise it would still be broken.

	Arnd <><
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/