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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 22 Mar 2011 15:02:48 +0100
From:	Florian Mickler <florian@...kler.org>
To:	James Bottomley <James.Bottomley@...senpartnership.com>
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>
Subject: Re: [PATCH 0/6] get rid of on-stack dma buffers

2011/3/22 James Bottomley <James.Bottomley@...senpartnership.com>:
> On Mon, 2011-03-21 at 22:03 +0100, Florian Mickler wrote:
>> On Mon, 21 Mar 2011 15:26:43 -0400
>> Andy Walls <awalls@...metrocast.net> wrote:
>>
>> > Florian Mickler <florian@...kler.org> 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...
>
> The API will round up so that the correct region covers the API.
> However, if you have other structures packed into the space (as very
> often happens on stack), you get cache line interference in the CPU if
> they get accessed:  The act of accessing an adjacent object pulls in
> cache above your object and destroys DMA coherence.  This is the
> principle reason why DMA to stack is a bad idea.

Thanks, this was the missing piece of information to make sense of
 why it's bad for stack memory to be part of this.

>
>> 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 did mean s/dma api/usb_control_msg/ in the above paragraph. As that is the
 ''dma api'' these drivers are using... sorry for the confusion there...

>
> No, it doesn't take any precautions like this.  the DMA API is just
> mapping (possibly via an IOMMU).  If the transfer times out, that's done
> in the DMA engine of the card, and must be cleaned up by the driver and
> unmapped.

ok.

> The general rule though is never DMA to stack.  On some processors, the
> way stack is allocated can actually make this not work.
>
> James

thanks,
Flo

p.s.: hope this message get's through to the list... I am on the road
at the moment,
 so I'm not shure that there won't be any html in it again :(
--
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/