Do Qualcomm drivers use DMA buffers for request_firmware_into_buf()?

[Bjorn Andersson]

On Thu 07 Jun 11:42 PDT 2018, Ard Biesheuvel wrote:

> On 7 June 2018 at 20:21, Bjorn Andersson <bjorn.andersson at linaro.org> 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