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]

Message-Id: <20090109.173057.25877173.nemoto@toshiba-tops.co.jp>
Date:	Fri, 09 Jan 2009 17:30:57 +0900 (JST)
From:	Atsushi Nemoto <anemo@....ocn.ne.jp>
To:	dan.j.williams@...el.com
Cc:	haavard.skinnemoen@...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

On Thu, 8 Jan 2009 10:20:56 -0700, "Dan Williams" <dan.j.williams@...el.com> wrote:
> On Thu, Jan 8, 2009 at 1:36 AM, Haavard Skinnemoen
> > 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.
> 
> True.
> 
> > 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...
> 
> A map and unmap should work for the current platforms with dma
> drivers, but you are right I think this is a violation of the api.
> For correctness we would need the entire operation covered by
> DMA_BIDIRECTIONAL to support platforms that may implement a dma bounce
> buffer.  Or, we could change dmatest to not go through the dma-memcpy
> api, allowing dma_alloc to be used for the destination.

Do you mean something like this?

		dmatest_init_srcbuf(thread->srcbuf, src_off, len);
		dmatest_init_dstbuf(thread->dstbuf, dst_off, len);

		dma_src = dma_map_single(dev->dev, src + src_off, len,
			 DMA_TO_DEVICE);
		dma_dest = dma_map_single(dev->dev, dest_buf, test_buf_size,
			DMA_BIDIRECTIONAL);
		tx = dev->device_prep_dma_memcpy(chan, dma_dest + dst_off,
				dma_src, len,
				DMA_CTRL_ACK | DMA_COMPL_SKIP_DEST_UNMAP);
		if (!tx) {
			/* error */
		}
		tx->callback = NULL;
		cookie = tx->tx_submit(tx);
		...
		/* wait for completion */
		...
		dma_unmap_single(dev->dev, dma_dest, test_buf_size,
			DMA_BIDIRECTIONAL);

It will make dmatest more aggressive, for example, a option for
testing DMA_PREP_INTERRUPT handling of a lowlevel driver can be added
easily.

---
Atsushi Nemoto
--
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/