Re: Updating cypress/brcm firmware in linux-firmware for CVE-2019-15126

[Chi-Hsien Lin <chi-hsien.lin@cypress.com>]

On 03/05/2020 10:00, Hans de Goede wrote:
> 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!
> 

First of all, the limits in clm_blob were tuned for each product (not 
really for each board, my bad) based on the real test data in the lab, 
so it's not just about the limits set by countries. Different product 
needs different configs even when being used in the same country and on 
the same channel.

The clm_blob came with previous firmware isn't really "generic". It's 
actually a collection of configs for many products. That collection is 
not comprehensive, so there will be products that it doesn't cover. If 
such product uses the firmware/clm_blob, it could violate regulatory. 
Cypress clm_blob may or may not cover Broadcom products.

To make it truly safe on linux-firmware.git, a real "geneirc" clm_blob 
would be needed. I'll leave that discussion to Chris.




> 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.
> 
> 
> 
> 
> .
>