On Thu 07 Jun 09:23 PDT 2018, Ard Biesheuvel wrote: > On 7 June 2018 at 18:18, Bjorn Andersson <bjorn.andersson@xxxxxxxxxx> wrote: > > On Wed 06 Jun 13:32 PDT 2018, Luis R. Rodriguez wrote: > > > >> On Fri, Jun 01, 2018 at 09:23:46PM +0200, Luis R. Rodriguez wrote: > >> > On Tue, May 08, 2018 at 03:38:05PM +0000, Luis R. Rodriguez wrote: > >> > > On Fri, May 04, 2018 at 12:44:37PM -0700, Martijn Coenen wrote: > >> > > > > >> > > > 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. > > > Thanks Ard, for filling in. > 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. > "The device" here refers to additional CPUs found in the Qualcomm SoCs, which executes firmware from the system's DDR memory. > 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. > I think these steps would relate to devices where we load firmware into the device. Here we're loading the firmware into DDR, setting up memory protection (locking out Linux), verifying the firmware and booting the CPU off the loaded and verified firmware. > 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? > The majority of these firmwares are position dependent, so we need to use reserved-memory carveouts to position these. The prior art of allocating this memory was dma_alloc_coherent(), but as this has size limitations we currently use memremap() to map these memory regions. There are some firmware that are position independent, so allocating the memory for these dynamically would be preferred, but as the any accesses to this memory region while the device is running would cause access violations we've been using dma_alloc_coherent(). (Although I think we've now reverted to using reserved-memory and memremap for these as well, as Arnd requested that we don't pass the dma_addr_t to our secure world firmware authenticator - i.e. we have no way of benefiting from CMA). So it's this memremap() region that we pass to request_firmware_into_buf() currently, the previously mentioned dma_alloc_coherent() region is used as we invoke the secure world operation to set up the firmware authentication. Regards, Bjorn _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
