From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bjorn Andersson Subject: Re: Do Qualcomm drivers use DMA buffers for request_firmware_into_buf()? Date: Mon, 25 Jun 2018 17:08:08 -0700 Message-ID: <20180626000808.GE1860@tuxbook-pro> References: <20180425175557.GY14440@wotan.suse.de> <20180508153805.GC27853@wotan.suse.de> <20180601192346.GQ4511@wotan.suse.de> <20180606203257.GH4511@wotan.suse.de> <20180607161847.GN510@tuxbook-pro> <20180607163308.GA18834@kroah.com> <20180607182117.GR510@tuxbook-pro> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: driverdev-devel-bounces@linuxdriverproject.org Sender: "devel" To: Ard Biesheuvel Cc: linux-efi , Matt Fleming , Will Deacon , Michal Hocko , David Howells , David Brown , Peter Jones , "H . Peter Anvin" , "open list:ANDROID DRIVERS" , linux-security-module , Nicolas Broeking , Jonathan Corbet , the arch/x86 maintainers , "Luis R. Rodriguez" , Ingo Molnar , Vlastimil Babka , Andy Gross , Darren Hart , Mimi Zohar , Arend Van Spriel , Todd Kjos , Kees Cook , Rik van Riel List-Id: linux-efi@vger.kernel.org On Thu 07 Jun 11:42 PDT 2018, Ard Biesheuvel wrote: > On 7 June 2018 at 20:21, Bjorn Andersson wrote: > > On Thu 07 Jun 09:33 PDT 2018, Greg Kroah-Hartman wrote: [..] > >> > >> Why not just use kmalloc, it will always return a DMAable buffer. > >> > > > > For the buffers being targeted by request_firmware_into_buf() the > > problem is that some of them has requirements of physical placement and > > they are all too big for kmalloc() (i.e. tens of mb). > > > > > > For the dma_alloc_coherent() buffer that was mentioned earlier, which is > > not related to the firmware loading, it's not used because the buffer is > > passed to secure world, which temporarily locks Linux out from the > > memory region. Traditionally this region was kmalloc'ed downstream, but > > due to speculative access violations this code moved to use the DMA > > streaming API, although there's no actual DMA going on. > > > > OK, so you are relying on the fact that dma_alloc_coherent() gives you > a device mapping (because the qcom_scm device is described as non > cache coherent), but this sounds risky to me. The linear alias of that > memory will still be mapped cacheable, and could potentially still be > accessed speculatively AFAIK. > Yes and we are aware of the risk of having the linear alias present, but have yet to find a suitable way to handle this. The proposed mechanism was to use reserved-memory and memremap() the region while it should be available in Linux, but while this would work for some cases (e.g. memory regions for semi-static firmware executed by co-processors) it doesn't handle the scenarios where the memory-need is dynamic. So suggestions are very welcome on how to better handle this. Regards, Bjorn