linux-kernel - Re: Do Qualcomm drivers use DMA buffers for request_firmware_into

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>] [day] [month] [year] [list]

Date:   Fri, 8 Jun 2018 08:41:28 +0200
From:   Vlastimil Babka <vbabka@...e.cz>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc:     Bjorn Andersson <bjorn.andersson@...aro.org>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Matt Fleming <matt@...eblueprint.co.uk>,
        Will Deacon <will.deacon@....com>,
        Michal Hocko <mhocko@...nel.org>,
        David Howells <dhowells@...hat.com>,
        David Brown <david.brown@...aro.org>,
        Peter Jones <pjones@...hat.com>,
        "Luis R. Rodriguez" <mcgrof@...nel.org>,
        "H . Peter Anvin" <hpa@...or.com>,
        "open list:ANDROID DRIVERS" <devel@...verdev.osuosl.org>,
        Nicolas Broeking <nbroeking@...com>,
        Jonathan Corbet <corbet@....net>,
        the arch/x86 maintainers <x86@...nel.org>,
        Arve Hj?nnev?g <arve@...roid.com>,
        Ingo Molnar <mingo@...hat.com>,
        Kalle Valo <kvalo@...eaurora.org>,
        Andy Gross <andy.gross@...aro.org>,
        Darren Hart <dvhart@...radead.org>,
        Mimi Zohar <zohar@...ux.vnet.ibm.com>,
        Arend Van Spriel <arend.vanspriel@...adcom.com>,
        Todd Kjos <tkjos@...roid.com>,
        Kees Cook <keescook@...omium.org>,
        linux-efi <linux-efi@...r.kernel.org>,
        Rik van Riel <riel@...riel.com>,
        linux-arm-msm@...r.kernel.org, Torsten Duwe <duwe@...e.de>,
        Josh Triplett <josh@...htriplett.org>,
        Chris Wright <chrisw@...s-sol.org>,
        Hans de Goede <hdegoede@...hat.com>,
        Andy Lutomirski <luto@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        platform-driver-x86@...r.kernel.org,
        Martijn Coenen <maco@...roid.com>,
        Alan Cox <alan@...ux.intel.com>,
        Martin Fuzzey <mfuzzey@...keon.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Vikram Mulukutla <markivx@...eaurora.org>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-security-module <linux-security-module@...r.kernel.org>,
        Dave Olsthoorn <dave@...aar.me>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Andy Shevchenko <andy@...radead.org>
Subject: Re: 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:
>> On 7 June 2018 at 18:18, Bjorn Andersson <bjorn.andersson@...aro.org> 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.
>>>
>>
>> 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
>