From: "Luis R. Rodriguez" <mcgrof@kernel.org>
To: Bjorn Andersson <bjorn.andersson@linaro.org>,
Vlastimil Babka <vbabka@suse.cz>
Cc: linux-efi <linux-efi@vger.kernel.org>,
Matt Fleming <matt@codeblueprint.co.uk>,
Will Deacon <will.deacon@arm.com>,
Michal Hocko <mhocko@kernel.org>,
David Howells <dhowells@redhat.com>,
David Brown <david.brown@linaro.org>,
Peter Jones <pjones@redhat.com>,
"H . Peter Anvin" <hpa@zytor.com>,
"open list:ANDROID DRIVERS" <devel@driverdev.osuosl.org>,
linux-security-module <linux-security-module@vger.kernel.org>,
Nicolas Broeking <nbroeking@me.com>,
Jonathan Corbet <corbet@lwn.net>,
the arch/x86 maintainers <x86@kernel.org>,
"Luis R. Rodriguez" <mcgrof@kernel.org>,
Ingo Molnar <mingo@redhat.com>,
Andy Gross <andy.gross@linaro.org>,
Darren Hart <dvhart@infradead.org>,
Mimi Zohar <zohar@linux.vnet.ibm.com>,
Arend Van Spriel <arend.vanspriel@broadcom.com>,
Todd Kjos <tkjos@android.com>, Kees Cook <keescook@chromium.org>,
Rik van Riel <riel@surriel.com>,
linux-arm-msm@vger.kern
Subject: Re: Do Qualcomm drivers use DMA buffers for request_firmware_into_buf()?
Date: Wed, 27 Jun 2018 20:00:59 +0200 [thread overview]
Message-ID: <20180627180059.GA21242@wotan.suse.de> (raw)
In-Reply-To: <20180626000808.GE1860@tuxbook-pro>
On Mon, Jun 25, 2018 at 05:08:08PM -0700, Bjorn Andersson wrote:
> On Thu 07 Jun 11:42 PDT 2018, Ard Biesheuvel wrote:
>
> > On 7 June 2018 at 20:21, Bjorn Andersson <bjorn.andersson@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,
That's still IO memory, and so it would be up to the specific device if
or not it could access the memory before a full write is done.
> 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.
I *believe* Vlastimil's seems to suggest kvmalloc(), but note that if getting the
memory to be contiguous fails, it would fallback to a non-contiguous (vmalloc)
allocation.
Luis
next prev parent reply other threads:[~2018-06-27 18:00 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-08 17:40 [PATCH v3 0/5] efi/firmware/platform-x86: Add EFI embedded fw support Hans de Goede
2018-04-08 17:40 ` [PATCH v3 1/5] efi: Export boot-services code and data as debugfs-blobs Hans de Goede
2018-04-16 8:23 ` Ard Biesheuvel
2018-04-24 13:11 ` Hans de Goede
2018-04-23 11:55 ` Greg Kroah-Hartman
2018-04-08 17:40 ` [PATCH v3 2/5] efi: Add embedded peripheral firmware support Hans de Goede
2018-04-16 8:28 ` Ard Biesheuvel
2018-04-24 13:17 ` Hans de Goede
2018-04-17 0:17 ` Luis R. Rodriguez
2018-04-17 8:58 ` Hans de Goede
2018-04-17 9:19 ` Hans de Goede
2018-04-23 21:11 ` Luis R. Rodriguez
2018-04-24 15:09 ` Hans de Goede
2018-04-24 16:07 ` Mimi Zohar
2018-04-24 18:33 ` Hans de Goede
2018-04-24 23:42 ` Luis R. Rodriguez
2018-04-25 5:00 ` Mimi Zohar
2018-04-25 17:55 ` Luis R. Rodriguez
2018-05-04 0:21 ` Luis R. Rodriguez
2018-05-04 15:26 ` Martijn Coenen
2018-05-04 19:44 ` Martijn Coenen
2018-05-08 15:38 ` Luis R. Rodriguez
2018-05-08 16:10 ` Luis R. Rodriguez
2018-06-07 16:49 ` Bjorn Andersson
2018-06-07 18:22 ` Luis R. Rodriguez
2018-06-01 19:23 ` Luis R. Rodriguez
2018-06-06 20:32 ` Do Qualcomm drivers use DMA buffers for request_firmware_into_buf()? Luis R. Rodriguez
2018-06-06 20:41 ` Ard Biesheuvel
2018-06-06 22:29 ` Luis R. Rodriguez
2018-06-06 22:41 ` Ard Biesheuvel
2018-06-06 22:55 ` Luis R. Rodriguez
2018-06-07 16:18 ` Bjorn Andersson
2018-06-07 16:23 ` Ard Biesheuvel
2018-06-07 16:33 ` Greg Kroah-Hartman
2018-06-07 16:43 ` Ard Biesheuvel
2018-06-07 16:49 ` Greg Kroah-Hartman
2018-06-07 16:56 ` Ard Biesheuvel
2018-06-07 18:21 ` Bjorn Andersson
2018-06-07 18:42 ` Ard Biesheuvel
2018-06-26 0:08 ` Bjorn Andersson
2018-06-27 18:00 ` Luis R. Rodriguez [this message]
2018-06-27 22:21 ` Ard Biesheuvel
2018-06-27 23:33 ` Luis R. Rodriguez
2018-06-27 23:42 ` Ard Biesheuvel
2018-06-27 23:50 ` Luis R. Rodriguez
2018-06-08 6:41 ` Vlastimil Babka
2018-06-07 18:06 ` Bjorn Andersson
2018-06-18 23:49 ` Luis R. Rodriguez
2018-06-07 16:33 ` [PATCH v3 2/5] efi: Add embedded peripheral firmware support Bjorn Andersson
2018-04-08 17:40 ` [PATCH v3 3/5] platform/x86: Rename silead_dmi to touchscreen_dmi Hans de Goede
2018-04-09 8:07 ` Andy Shevchenko
2018-04-20 0:20 ` Darren Hart
2018-04-08 17:40 ` [PATCH v3 4/5] platform/x86: touchscreen_dmi: Add EFI embedded firmware info support Hans de Goede
2018-04-08 17:40 ` [PATCH v3 5/5] platform/x86: touchscreen_dmi: Add info for the Chuwi Vi8 Plus tablet Hans de Goede
2018-04-09 8:10 ` Andy Shevchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180627180059.GA21242@wotan.suse.de \
--to=mcgrof@kernel.org \
--cc=andy.gross@linaro.org \
--cc=arend.vanspriel@broadcom.com \
--cc=bjorn.andersson@linaro.org \
--cc=corbet@lwn.net \
--cc=david.brown@linaro.org \
--cc=devel@driverdev.osuosl.org \
--cc=dhowells@redhat.com \
--cc=dvhart@infradead.org \
--cc=hpa@zytor.com \
--cc=keescook@chromium.org \
--cc=linux-arm-msm@vger.kern \
--cc=linux-efi@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=matt@codeblueprint.co.uk \
--cc=mhocko@kernel.org \
--cc=mingo@redhat.com \
--cc=nbroeking@me.com \
--cc=pjones@redhat.com \
--cc=riel@surriel.com \
--cc=tkjos@android.com \
--cc=vbabka@suse.cz \
--cc=will.deacon@arm.com \
--cc=x86@kernel.org \
--cc=zohar@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).