public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Victor Bravo <1905@spmblk.com>
To: Arend van Spriel <arend.vanspriel@broadcom.com>,
	Franky Lin <franky.lin@broadcom.com>,
	Hante Meuleman <hante.meuleman@broadcom.com>,
	Chi-Hsien Lin <chi-hsien.lin@cypress.com>,
	Wright Feng <wright.feng@cypress.com>,
	Kalle Valo <kvalo@codeaurora.org>,
	"David S. Miller" <davem@davemloft.net>,
	linux-wireless@vger.kernel.org,
	brcm80211-dev-list.pdl@broadcom.com,
	brcm80211-dev-list@cypress.com, linux-kernel@vger.kernel.org
Subject: PROBLEM: brcmfmac's DMI-based fw file names break built-in fw loader
Date: Sat, 4 May 2019 18:26:33 +0200	[thread overview]
Message-ID: <20190504162633.ldrz2nqfocg55grb@localhost> (raw)

The brcmfmac driver seems to have partially fixed problems which
prevented it to be used in shared system/kernel images for multiple
hardware by trying to load it's <config>.txt as
<config>.<dmi_sys_vendor>.<dmi_product_name>.txt first and then
falling back to <config>.txt. Real-life example:

brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43340-sdio.ASUSTeK COMPUTER INC.-T100HAN.txt failed with
error -2
brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43340-sdio for chip
BCM43340/2

Unfortunately this doesn't really help on systems which use static
kernel with firmware blobs (and also text configuration files in case of
brcmfmac) built-in using CONFIG_EXTRA_FIRMWARE, as CONFIG_EXTRA_FIRMWARE
doesn't support spaces in file names - kernel build fails with

CONFIG_EXTRA_FIRMWARE="brcm/brcmfmac43340-sdio.bin brcm/brcmfmac43340-sdio.ASUSTeK COMPUTER INC.-T100HAN.txt"

for obvious reasons. So the only way here is to stay with good old
brcmfmac43340-sdio.txt and support at most one brcmfmac-equipped machine
per kernel image.

Please consider filtering the DMI strings and replacing spaces and
possibly other invalid characters with underscores, and/or adding module
parameter to allow passing the string from command line (using
brcmfmac.tag=t100 or brcmfmac.board=t100 to make the module load
brcmfmac43340-sdio.t100.txt seems nicer to me, and isn't prone to
breaking when DMI strings change on BIOS update).

My brief grep-based research also suggest that strings retrieved
by dmi_get_system_info() are passed to firmware loader without any
checks for special character, /../ etc. I'm not sure whether this is
considered to be proper & safe use, but if it's not, it may also have
some security implications, as it allows attacker with access to DMI
strings (using root rights/other OS/BIOS/physical access) to mess
with kernel space or secure boot.

I would also really appreciate not allowing future brcm (and other)
drivers to leave staging area before they fully support =y.

Regards,
v.b.

             reply	other threads:[~2019-05-04 16:33 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-04 16:26 Victor Bravo [this message]
2019-05-04 19:11 ` PROBLEM: brcmfmac's DMI-based fw file names break built-in fw loader Arend Van Spriel
2019-05-04 19:44   ` Victor Bravo
2019-05-05  8:20     ` Arend Van Spriel
2019-05-05 14:36       ` Victor Bravo
2019-05-05 14:48       ` [PATCH RFC] brcmfmac: sanitize DMI strings Victor Bravo
2019-05-05 14:52         ` Victor Bravo
2019-05-05 15:03       ` [PATCH RFC] brcmfmac: sanitize DMI strings v2 Victor Bravo
2019-05-06  8:13         ` Hans de Goede
2019-05-06  8:42           ` Kalle Valo
2019-05-06  9:14             ` Victor Bravo
2019-05-06 12:29               ` Kalle Valo
2019-05-06 14:06                 ` Victor Bravo
2019-05-06  9:06           ` Victor Bravo
2019-05-06  9:33             ` Hans de Goede
2019-05-06 10:20               ` Victor Bravo
2019-05-06 10:34                 ` Hans de Goede
2019-05-06 12:26                   ` Kalle Valo
2019-05-06 15:24                     ` Victor Bravo
2019-05-06 16:05                       ` Hans de Goede
2019-05-06 19:30                         ` Arend Van Spriel
2019-05-07 15:38                           ` Hans de Goede
2019-05-13  9:21                             ` Arend Van Spriel
2019-05-06  8:44         ` Kalle Valo

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=20190504162633.ldrz2nqfocg55grb@localhost \
    --to=1905@spmblk.com \
    --cc=arend.vanspriel@broadcom.com \
    --cc=brcm80211-dev-list.pdl@broadcom.com \
    --cc=brcm80211-dev-list@cypress.com \
    --cc=chi-hsien.lin@cypress.com \
    --cc=davem@davemloft.net \
    --cc=franky.lin@broadcom.com \
    --cc=hante.meuleman@broadcom.com \
    --cc=kvalo@codeaurora.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=wright.feng@cypress.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