mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: Victor Bravo <1905@spmblk.com>,
	Arend Van Spriel <arend.vanspriel@broadcom.com>
Cc: 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: Re: [PATCH RFC] brcmfmac: sanitize DMI strings v2
Date: Mon, 6 May 2019 10:13:38 +0200	[thread overview]
Message-ID: <0f75a3d4-94af-5503-94c3-e8af2364448d@redhat.com> (raw)
In-Reply-To: <20190505150355.3fbng4ny34x255vk@localhost>

Hi,

On 05-05-19 17:03, Victor Bravo wrote:
> Sanitize DMI strings in brcmfmac driver to make resulting filenames
> contain only safe characters. This version replaces all non-printable
> characters incl. delete (0-31, 127-255), spaces and slashes with
> underscores.
> 
> This change breaks backward compatibility, but adds control over strings
> passed to firmware loader and compatibility with CONFIG_EXTRA_FIRMWARE
> which doesn't support spaces in filenames.
> 
> Changes from v1: don't revert fresh commit by someone else
> 
> Signed-off-by: Victor Bravo <1905@spmblk.com>

Thank you for the patch, but I'm sorry to say this patch cannot go in as is,
because it will break existing systems.

If you look here:

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/brcm

You will see a file named: "brcmfmac43430a0-sdio.ONDA-V80 PLUS.txt" there, which
has a space in its name (and which works fine).

I'm fine with doing some sanitizing of the strings, but replacing spaces with _
breaks existing use-cases (will cause a regression for them) and a space is absolutely
a valid character in a filename and the firmware-loader can deal with this just fine.

If the code for building firmwares into the kernel cannot deal with spaces then IMHO
that code should be fixed instead. Have you looked into fixing that?

As for your T100HA example from earlier in this thread, the brcmfmac driver now
also supports getting the firmware from a special EFI nvram variable, which the
T100HA sets, so you do not need to provide a nvram file on the T100HA and things
will still work.

> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c
> index 7535cb0d4ac0..84571e09b465 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c
> @@ -23,6 +23,14 @@
>   /* The DMI data never changes so we can use a static buf for this */
>   static char dmi_board_type[128];
>   
> +/* Array of 128 bits representing 7-bit characters allowed in DMI strings. */
> +static unsigned char brcmf_dmi_allowed_chars[] = {
> +	0x00, 0x00, 0x00, 0x00, 0xfe, 0x7f, 0xff, 0xff,
> +	0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x7f
> +};
> +
> +#define BRCMF_DMI_SAFE_CHAR '_'
> +
>   struct brcmf_dmi_data {
>   	u32 chip;
>   	u32 chiprev;
> @@ -99,6 +107,15 @@ static const struct dmi_system_id dmi_platform_data[] = {
>   	{}
>   };
>   
> +void brcmf_dmi_sanitize(char *dst, const unsigned char *allowed, char safe)
> +{
> +	while (*dst) {
> +		if ((*dst < 0) || !(allowed[*dst / 8] & (1 << (*dst % 8))))

At a first look I have no clue what this code is doing and I honestly do not feel
like figuring it out, this is clever, but IMHO not readable.

Please just write this as if (*dst < 0x21 || (*dst > foo && < bar) || etc,
so that a human can actually see in one look what the code is doing.

You may want to wait for Arend to give his opinion before changing this though,
maybe he likes the code as is.

Also note that that should be < 0x20 of course, since we need to preserve spaces
as is to avoid a regression.

Regards,

Hans





> +			*dst = safe;
> +		dst++;
> +	}
> +}
> +
>   void brcmf_dmi_probe(struct brcmf_mp_device *settings, u32 chip, u32 chiprev)
>   {
>   	const struct dmi_system_id *match;
> @@ -126,6 +143,9 @@ void brcmf_dmi_probe(struct brcmf_mp_device *settings, u32 chip, u32 chiprev)
>   	if (sys_vendor && product_name) {
>   		snprintf(dmi_board_type, sizeof(dmi_board_type), "%s-%s",
>   			 sys_vendor, product_name);
> +		brcmf_dmi_sanitize(dmi_board_type,
> +				   brcmf_dmi_allowed_chars,
> +				   BRCMF_DMI_SAFE_CHAR);
>   		settings->board_type = dmi_board_type;
>   	}
>   }
> 

  reply	other threads:[~2019-05-06  8:13 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-04 16:26 PROBLEM: brcmfmac's DMI-based fw file names break built-in fw loader Victor Bravo
2019-05-04 19:11 ` 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 [this message]
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=0f75a3d4-94af-5503-94c3-e8af2364448d@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=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

Powered by JetHome