Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp2231979yba; Mon, 6 May 2019 02:07:14 -0700 (PDT) X-Google-Smtp-Source: APXvYqw37WiN8/724oxeTl/0THhsICn/BNdXqld+AjHft2BswOrmbYduF4KM/yYik1JzCAivbKwa X-Received: by 2002:a62:4115:: with SMTP id o21mr31704782pfa.153.1557133633953; Mon, 06 May 2019 02:07:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557133633; cv=none; d=google.com; s=arc-20160816; b=r1emJCx63ARc9OoeZE1Ygj3OChnchugVGSOb81n1Lwn9RwVW68lxhyL7jQLwgdm0tU IxS7t55xFTFJIRlzOglIJCcImhjklaiu51KOP6FkARuc1U73wf54Msyysm3KUJG1EayA T0pgjHJKvhTueYE2m6yhKPSGnTVZ2HrOq8uMKo932rpBJ5PQ0zKmYbqWDYXGJ+RuZcLG x5RsIMbMkDkYXF+g7cLlWosQO98O6ly4QkidlEQVB7/ev2jL/O7jqYCp2fuoR5pZnyai M7tq11HkRc2ItyG14COvWYDQNf9A/YSiye8ylikaGw9IuW7EhcGR9ASlSsg7I3q5gmvt EcLg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=5zNGVzB+NOMhVBa76HfLnFXyKd3Hxjr1TTnqwNY5V9A=; b=ev/YB64JWHuVPlixOuCFoV8VPE5FkZIjZf94pWfYtsC+3AlxcM5ympT9CbyZXKT0mo 7pk1PgLuqxRVudhhTTIkxbV1rxOaApV/27ghkdvIc2HMVE4W+8H6wEiEknmnyTADvnfI 1VO913EXvtz7BXKSa3WxUU1qsurNSS9gw7TTG4ihBUY9q2V99XLwlEeFB+ZnViLnbY63 FS08nt/+hYzcd9K83T87yqTrEfVOLawGKE1xmtdWOy1cEtYsp1Zi2bMHub29BeZMjBYd cTEKX5VyMsGw4438Qerr67x76aukD4WJcPxLA5HtDpmurawXGahK8B/LoWM9HjshA3t5 hsgA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m15si673437pfh.46.2019.05.06.02.06.53; Mon, 06 May 2019 02:07:13 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726340AbfEFJGS (ORCPT + 99 others); Mon, 6 May 2019 05:06:18 -0400 Received: from 0.ictbs.com ([203.137.112.168]:58978 "EHLO 0.ictbs.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725890AbfEFJGS (ORCPT ); Mon, 6 May 2019 05:06:18 -0400 Received: by hq.local (Postfix, from userid 1000) id 3284766429; Mon, 6 May 2019 11:06:09 +0200 (CEST) Date: Mon, 6 May 2019 11:06:09 +0200 From: Victor Bravo <1905@spmblk.com> To: Hans de Goede Cc: Arend Van Spriel , Franky Lin , Hante Meuleman , Chi-Hsien Lin , Wright Feng , Kalle Valo , "David S. Miller" , 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 Message-ID: <20190506090609.msudhncj7e5vdtzw@localhost> References: <20190504162633.ldrz2nqfocg55grb@localhost> <20190504194440.4zcxjrtj2aft3ka4@localhost> <16a87149068.2764.9b12b7fc0a3841636cfb5e919b41b954@broadcom.com> <20190505150355.3fbng4ny34x255vk@localhost> <0f75a3d4-94af-5503-94c3-e8af2364448d@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0f75a3d4-94af-5503-94c3-e8af2364448d@redhat.com> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On Mon, May 06, 2019 at 10:13:38AM +0200, Hans de Goede wrote: > Hi, 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). Thanks for the updates. Spaces are actually a problem as files with spaces don't work when built-in with CONFIG_EXTRA_FIRMWARE (which is used with non-modular kernel containing brcmfmac driver). If the DMI string contains slashes, they will cause problems for obvious reasons too. > 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? Yes, but updating CONFIG_EXTRA_FIRMWARE to support spaces because of this looks much like fixing systemd-caused unitialized urandom reads on kernel side. Do you really think it's a good idea to propose that in this case? > 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. I don't really get this. Can you please suggest how do I make the driver use something different than "brcmfmac43340-sdio.txt" or "brcmfmac43340-sdio.ASUSTeK COMPUTER INC.-T100HAN.txt" on T100HAN? > > 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. Understood. The cluless part actually checks corresponding bit in allowed array, which is a bit mask describing what characters are allowed or not. > 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. This has been already discussed, spaces are a problem. There even was an opinion that adding the code that doesn't bother with spaces and slashes might be a regression as well. Regards, v. > 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; > > } > > } > > >