linux-kernel - [RFC/PATCH 0/4] request_firmware() on memory constrained devices

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

Message-Id: <1457428939-26659-1-git-send-email-stephen.boyd@linaro.org>
Date:	Tue,  8 Mar 2016 16:22:15 +0700
From:	Stephen Boyd <stephen.boyd@...aro.org>
To:	linux-kernel@...r.kernel.org
Cc:	linux-arm@...ts.infradead.org,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Robin Murphy <robin.murphy@....com>,
	Laura Abbott <labbott@...hat.com>,
	Arnd Bergmann <arnd@...db.de>,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	Mimi Zohar <zohar@...ux.vnet.ibm.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Mark Brown <broonie@...nel.org>,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will.deacon@....com>
Subject: [RFC/PATCH 0/4] request_firmware() on memory constrained devices

Some systems are memory constrained but they need to load very
large firmwares. The firmware subsystem allows drivers to request
this firmware be loaded from the filesystem, but this requires
that the entire firmware be loaded into kernel memory first
before it's provided to the driver. This can lead to a situation
where we map the firmware twice, once to load the firmware into
kernel memory and once to copy the firmware into the final
resting place.

This design creates needless memory pressure and delays loading
because we have to copy from kernel memory to somewhere else.
This patch sets adds support to the request firmware and DMA APIs
to map DMA buffers a page at a time and load the firmware directly
into those pages, skipping the intermediate copying step and
alleviating memory pressure during firmware loading. The drawback
is that we can't use the firmware caching feature because the
memory for the firmware cache is never allocated.

Patches based on v4.5-rc1.

Laura Abbott (1):
  dma-mapping: Add dma_remap() APIs

Stephen Boyd (2):
  ARM64: dma: Add support for NO_KERNEL_MAPPING attribute
  firmware: Support requesting firmware directly into DMA memory

Vikram Mulukutla (1):
  firmware_class: Provide infrastructure to make fw caching optional

 arch/arm64/mm/dma-mapping.c   |  78 +++++++++++--
 drivers/base/firmware_class.c | 263 ++++++++++++++++++++++++++++++++----------
 include/linux/dma-mapping.h   |  35 ++++++
 include/linux/firmware.h      |  13 +++
 4 files changed, 316 insertions(+), 73 deletions(-)

-- 
2.7.0.25.gfc10eb5