linux-kernel - Re: [PATCH 0/6] get rid of on-stack dma buffers

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: <alpine.LRH.2.00.1103221157510.8710@twin.jikos.cz>
Date:	Tue, 22 Mar 2011 11:59:32 +0100 (CET)
From:	Jiri Kosina <jkosina@...e.cz>
To:	Florian Mickler <florian@...kler.org>
Cc:	Andy Walls <awalls@...metrocast.net>, mchehab@...radead.org,
	linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
	js@...uxtv.org, tskd2@...oo.co.jp, liplianin@...by,
	g.marco@...enet.de, aet@...terburn.org, pb@...uxtv.org,
	mkrufky@...uxtv.org, nick@...k-andrew.net, max@...eto.com,
	janne-dvb@...nau.be, Oliver Neukum <oliver@...kum.org>,
	Greg Kroah-Hartman <greg@...ah.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Joerg Roedel <joerg.roedel@....com>,
	James Bottomley <James.Bottomley@...senPartnership.com>
Subject: Re: [PATCH 0/6] get rid of on-stack dma buffers

On Mon, 21 Mar 2011, Florian Mickler wrote:

> To be blunt, I'm not shure I fully understand the requirements myself. 
> But as far as I grasped it, the main problem is that we need memory 
> which the processor can see as soon as the device has scribbled upon it. 
> (think caches and the like)
> 
> Somewhere down the line, the buffer to usb_control_msg get's to be a 
> parameter to dma_map_single which is described as part of the DMA API in 
> Documentation/DMA-API.txt
> 
> The main point I filter out from that is that the memory has to begin
> exactly at a cache line boundary... 
> 
> I guess (not verified), that the dma api takes sufficient precautions to 
> abort the dma transfer if a timeout happens.  So freeing _should_ not be 
> an issue. (At least, I would expect big fat warnings everywhere if that 
> were the case)
> 
> I cc'd some people that hopefully will correct me if I'm wrong...

It all boils down to making sure that you don't free the memory which is 
used as target of DMA transfer.

This is very likely to hit you when DMA memory region is on stack, but 
blindly just converting this to kmalloc()/kfree() isn't any better if you 
don't make sure that all the DMA transfers have been finished and device 
will not be making any more to that particular memory region.

-- 
Jiri Kosina
SUSE Labs, Novell Inc.

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