linux-kernel - Re: [PATCH v2] media: venus: don't abuse dma

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAK8P3a324F5GffbwNRmhEM-zTFM+tAqyJ-5oEjetR2ZfhPzYtw@mail.gmail.com>
Date:   Thu, 20 Jul 2017 13:46:36 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Hans Verkuil <hverkuil@...all.nl>
Cc:     Stanimir Varbanov <stanimir.varbanov@...aro.org>,
        Linux Media Mailing List <linux-media@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH v2] media: venus: don't abuse dma_alloc for non-DMA allocations

On Thu, Jul 20, 2017 at 1:26 PM, Hans Verkuil <hverkuil@...all.nl> wrote:
> On 19/07/17 13:51, Stanimir Varbanov wrote:
>> In venus_boot(), we pass a pointer to a phys_addr_t
>> into dmam_alloc_coherent, which the compiler warns about:
>>
>> platform/qcom/venus/firmware.c: In function 'venus_boot':
>> platform/qcom/venus/firmware.c:63:49: error: passing argument 3 of 'dmam_alloc_coherent' from incompatible pointer type [-Werror=incompatible-pointer-types]
>>
>> To avoid the error refactor venus_boot function by discard
>> dma_alloc_coherent invocation because we don't want to map the
>> memory for the device.  Something more, the usage of
>> DMA mapping API is actually wrong and the current
>> implementation relies on several bugs in DMA mapping code.
>> When these bugs are fixed that will break firmware loading,
>> so fix this now to avoid future troubles.
>>
>> The meaning of venus_boot is to copy the content of the
>> firmware buffer into reserved (and memblock removed)
>> block of memory and pass that physical address to the
>> trusted zone for authentication and mapping through iommu
>> form the secure world. After iommu mapping is done the iova
>> is passed as ane entry point to the remote processor.
>>
>> After this change memory-region property is parsed manually
>> and the physical address is memremap to CPU, call mdt_load to
>> load firmware segments into proper places and unmap
>> reserved memory.
>>
>> Fixes: af2c3834c8ca ("[media] media: venus: adding core part and helper functions")
>> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@...aro.org>
>
> Arnd, is this OK for you?

Looks good

Reviewed-by: Arnd Bergmann <arnd@...db.de>