From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_NEOMUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8BB9FC04A6B for ; Mon, 6 May 2019 15:24:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 64476205ED for ; Mon, 6 May 2019 15:24:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726834AbfEFPYs (ORCPT ); Mon, 6 May 2019 11:24:48 -0400 Received: from 0.ictbs.com ([203.137.112.168]:33899 "EHLO 0.ictbs.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726680AbfEFPYr (ORCPT ); Mon, 6 May 2019 11:24:47 -0400 Received: by hq.local (Postfix, from userid 1000) id 6287766429; Mon, 6 May 2019 17:24:41 +0200 (CEST) Date: Mon, 6 May 2019 17:24:41 +0200 From: Victor Bravo <1905@spmblk.com> To: Kalle Valo Cc: Hans de Goede , Arend Van Spriel , Franky Lin , Hante Meuleman , Chi-Hsien Lin , Wright Feng , "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: <20190506152441.ifjcdi73elxuq5it@localhost> References: <20190504194440.4zcxjrtj2aft3ka4@localhost> <16a87149068.2764.9b12b7fc0a3841636cfb5e919b41b954@broadcom.com> <20190505150355.3fbng4ny34x255vk@localhost> <0f75a3d4-94af-5503-94c3-e8af2364448d@redhat.com> <20190506090609.msudhncj7e5vdtzw@localhost> <70677dff-4336-28d5-7ab9-7ba7c3d74ebc@redhat.com> <20190506102032.3ximjecado4mz62j@localhost> <87d0kvvkej.fsf@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87d0kvvkej.fsf@codeaurora.org> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 06, 2019 at 03:26:28PM +0300, Kalle Valo wrote: > Hans de Goede writes: > > > If we're going to do some filtering, then I suggest we play it safe and also > > disallow other chars which may be used as a separator somewhere, specifically > > ':' and ','. > > > > Currently upstream linux-firmware has these files which rely on the DMI > > matching: > > > > brcmfmac4330-sdio.Prowise-PT301.txt > > brcmfmac43430-sdio.Hampoo-D2D3_Vi8A1.txt > > brcmfmac43430a0-sdio.ONDA-V80 PLUS.txt > > > > The others are either part of the DMI override table for devices with unsuitable > > DMI strings like "Default String"; or are device-tree based. > > > > So as long as we don't break those 3 (or break the ONDA one but get a symlink > > in place) we can sanitize a bit more then just non-printable and '/'. > > > > Kalle, Arend, what is your opinion on this? > > > > Note I do not expect the ONDA V80 Plus to have a lot of Linux users, > > but it definitely has some. > > To me having spaces in filenames is a bad idea, but on the other hand we > do have the "don't break existing setups" rule, so it's not so simple. I > vote for not allowing spaces, I think that's the best for the long run, > but don't know what Arend thinks. I have found a fresh judicate on this: https://lkml.org/lkml/2018/12/22/221 It seems clear that we have to support at least spaces for some time (maybe wih separate config option which will be deprecated but on by defaut until old files are considered gone). > Maybe we could do some kind of fallback mechanism, like first trying the > sanitised filename and if that's not found then we try the old filename > with spaces? And if that old filename works we print a big fat warning > that the user should update the file and that the old "filename with > spaces" support is going away soon? In case of parametric sanitizing function, this might be achievable by sanitizing using "final" character set first, and falling back to "compatible" character set on file not found. So this may actually bring another requirement on the sanitizing function. Regards, v.