linux-kernel - Re: [PATCH] dmatest: flush and invalidate destination buffer before DMA

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:	Thu, 8 Jan 2009 09:36:03 +0100
From:	Haavard Skinnemoen <haavard.skinnemoen@...el.com>
To:	Atsushi Nemoto <anemo@....ocn.ne.jp>
Cc:	dan.j.williams@...el.com, linux-kernel@...r.kernel.org,
	maciej.sosnowski@...el.com, ralf@...ux-mips.org
Subject: Re: [PATCH] dmatest: flush and invalidate destination buffer before
 DMA

Atsushi Nemoto wrote:
> I should argue another reason to do writeback/invalidate here in
> dmatest for non-coherent archs (not only for MIPS).
> 
> The dmatest compares dstbuf outside the real DMA region to detect
> illegal overwriting.  But on non-coherent archs, this comparison just
> validates contents of cache, not main memory.  So dmatest might not
> able to detect illegal overwriting.  Doing writeback/invalidate
> _whole_ dstbuf are before dma_async_memcpy_buf_to_buf() will make
> dmatest more strict.
> 
> This is why I used DMA_BIDIRECTIONAL for whole dstbuf area rather than
> DMA_TO_DEVICE for two cache lines on both edges of the real DMA area.
> 
> Doesn't this make sense?

I think it does. The dmatest driver should definitely use
DMA_BIDIRECTIONAL on the destination buffer to ensure that the poison
values are written to RAM and not just written to cache and discarded.

Now, this probably means that the destination buffer must be _unmapped_
with DMA_BIDIRECTIONAL too, which is difficult to do with the current
asymmetrical API...

In the general case, however, I think MIPS has a bug: I've seen drivers
DMA to/from tiny buffers stored inside another struct. This is legal
because the driver can guarantee that the other fields in the struct
aren't accessed in the mean time, but any fields sharing a cacheline
with the buffer must be written back before the lines are invalidated.

Haavard
--
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/