Message-ID: <e6c7ec6c-8619-1511-8626-70ebdea3cec5@redhat.com>
Date:   Thu, 5 Mar 2020 15:00:18 +0100
From:   Hans de Goede <hdegoede@...hat.com>
To:     David Woodhouse <dwmw2@...radead.org>, chi-hsien.lin@...ress.com,
        Christopher Rumpf <Christopher.Rumpf@...ress.com>,
        Chung-Hsien Hsu <cnhu@...ress.com>
Cc:     linux-firmware@...nel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Updating cypress/brcm firmware in linux-firmware for
 CVE-2019-15126

Hi,

On 3/5/20 10:16 AM, David Woodhouse wrote:
> On Thu, 2020-03-05 at 07:24 +0100, Hans de Goede wrote:
>>> also clm_blob download is not supported in kernels prior to 4.15 so
>>> those files won't work with older kernels.
>>
>> That is a valid concern, I'm not sure what the rules for linux-firmware
>> are with regards to this.
> 
> Not quite sure I understand the problem.
> 
> The rules for Linux firmware are just the same as basic engineering
> practice for loadable libraries.
> 
> If you change the ABI, you change the "soname" of a library, which
> equates to changing the filename of a linux-firmware object.
> 
> So if you make a new file format for the firmware which requires new
> driver support, then you give it a new name. The updated driver can
> attempt to load the old firmware filename as a fallback, if it still
> supports that, or you just have a clean separation between the two.
> 
> The linux-firmware repository then carries *both* files, supporting
> both old and new kernels in parallel.

That is true, adding support to the brcm drivers for that should
be easy enough and backporting that to older still supported drivers
(which already support the separate regulatory db the new firmware
uses) should also be easy enough.

So that removes one concern, leaving just the regulatory concerns.

To be honest I do not completely understand the regulatory concerns
about using the drivers from the SDK.

Chi-hsien, you say that the clm_blob files from the Cypress SDK are
only valid for the Cypress reference designs, but AFAIK the clm_blob
only contains per country regulatory info, so which channels can
be used, how much mW/dB signal strength is allowed in those channels,
etc.  Which I would expect to not change on a per design basis.
Parameters which can change on a per design basis like antenna gain,
are stored in the nvram and not part of the clm_blob (AFAIK).

So I still do not understand why using the clm_blob files files from
the SDK would be a problem? Can you explain this in more detail?

Even if the clm_blob as distributed in the SDK is a problem, then
I believe there should be a way to make a generic clm_blob which
is not tied to the reference designs. The current brcm firmware
files in linux-firmware have such a generic clm_blob builtin,
if one can be builtin, then it should be possible to also create
a generic clm_blob for the newer style firmware where the clm_blob
is a separate binary ?

Note that going this route (combined with different names for the
new style firmware so that we can keep the old files for old kernels)
will mean less work for Cypress. I believe that the current problem
is that Cypress needs to do firmware builds for each chipset twice,
once for the new-style format used inside Cypress' SDK and once for
the old-style format used in linux-firmware. And it seems that there
are not enough resources to do the old-style builds causing the firmware
versions in linux-firmware to lag behind by multiple years!

Regards,

Hans



p.s.

Also note that the Linux 802.11 stack already takes care of only
selecting channels which are allowed in the country where the wifi
card is (as advertised by the access-point). AFAIK by some other
vendors this alone is enough for regulatory concerns and there is
no firmware level country settting.

Powered by blists - more mailing lists