Do Qualcomm drivers use DMA buffers for request_firmware_into_buf()?

On 06/07/2018 06:33 PM, Greg Kroah-Hartman wrote:

On Thu, Jun 07, 2018 at 06:23:01PM +0200, Ard Biesheuvel wrote:

quoted

On 7 June 2018 at 18:18, Bjorn Andersson [off-list ref] wrote:

quoted

On Wed 06 Jun 13:32 PDT 2018, Luis R. Rodriguez wrote:

quoted

On Fri, Jun 01, 2018 at 09:23:46PM +0200, Luis R. Rodriguez wrote:

quoted

On Tue, May 08, 2018 at 03:38:05PM +0000, Luis R. Rodriguez wrote:

quoted

On Fri, May 04, 2018 at 12:44:37PM -0700, Martijn Coenen wrote:

quoted

I think the Qualcomm folks owning this (Andy, David, Bjorn, already
cc'd here) are better suited to answer that question.

Andy, David, Bjorn?

Andy, David, Bjorn?

A month now with no answer...

The patch at the top of this thread doesn't interest me and you didn't
bother sending your question To me.

As a matter of fact I'm confused to what the actual question is.

The actual question is whether it is really required that the firmware
is loaded by the kernel into a buffer that is already mapped for DMA
at that point, and thus accessible by the device.

To me, it is not entirely clear what the nature is of the firmware
that we are talking about, since it seems to be getting passed to the
secure world as well?

In any case, the preferred model in terms of validation/sig checking is

1) allocate a CPU accessible buffer

2) request the firmware into it (which may include a sig check under the hood)

3) map the buffer for DMA to the device so it can load the firmware.

4) kick off the DMA transfer.

The use of dma_alloc_coherent() for this purpose seems unnecessary,
given that the DMA transfer is not bidirectional. Would it be possible
to replace it with something like the above sequence?

Why not just use kmalloc, it will always return a DMAable buffer.

DMAble in what sense? For devices that can't handle physical addresses
above 16M you need to pass __GFP_DMA to get those, from ZONE_DMA.
Otherwise it can return anything from lowmem. That's for x86_64, some
other arches have different DMA zone.

Is the problem that vmalloc() might not?

vmalloc() could only be used as an alternative if you used kvmalloc(),
otherwise kmalloc() won't give you anything from vmalloc

We need to drop the whole DMA zone crud, it confuses everyone who sees
it and was primarily for really really old systems.

Yeah that would be nice.

greg k-h

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html