Re: [PATCH RFC] brcmfmac: sanitize DMI strings v2

From: Victor Bravo <1905@spmblk.com>
To: Kalle Valo <kvalo@codeaurora.org>
Cc: Hans de Goede <hdegoede@redhat.com>,
	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>,
	"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 17:24:41 +0200	[thread overview]
Message-ID: <20190506152441.ifjcdi73elxuq5it@localhost> (raw)
In-Reply-To: <87d0kvvkej.fsf@codeaurora.org>

On Mon, May 06, 2019 at 03:26:28PM +0300, Kalle Valo wrote:
> Hans de Goede <hdegoede@redhat.com> 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.