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

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

[Hans de Goede]

Hello Cypress people,

Can we please get updated firmware for
brcm/brcmfmac4356-pcie.bin and brcm/brcmfmac4356-sdio.bin
fixing CVE-2019-15126 as well as for any other affected
models (the 4356 is explicitly named in the CVE description) ?

The current Cypress firmware files in linux-firmware are
quite old, e.g. for brcm/brcmfmac4356-pcie.bin linux-firmware has:
version 7.35.180.176 dated 2017-10-23, way before the CVE

Where as https://community.cypress.com/docs/DOC-19000 /
cypress-fmac-v4.14.77-2020_0115.zip has:
version 7.35.180.197 which presumably contains a fix (no changelog)

Regards,

Hans

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

[Hans de Goede]

Hello Cypress people,

Can we please get updated firmware for
brcm/brcmfmac4356-pcie.bin and brcm/brcmfmac4356-sdio.bin
fixing CVE-2019-15126 as well as for any other affected
models (the 4356 is explicitly named in the CVE description) ?

The current Cypress firmware files in linux-firmware are
quite old, e.g. for brcm/brcmfmac4356-pcie.bin linux-firmware has:
version 7.35.180.176 dated 2017-10-23, way before the CVE

Where as https://community.cypress.com/docs/DOC-19000 /
cypress-fmac-v4.14.77-2020_0115.zip has:
version 7.35.180.197 which presumably contains a fix (no changelog)

Regards,

Hans

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

[Hans de Goede]

Hi,

On 2/26/20 11:16 PM, Hans de Goede wrote:
> Hello Cypress people,
> 
> Can we please get updated firmware for
> brcm/brcmfmac4356-pcie.bin and brcm/brcmfmac4356-sdio.bin
> fixing CVE-2019-15126 as well as for any other affected
> models (the 4356 is explicitly named in the CVE description) ?
> 
> The current Cypress firmware files in linux-firmware are
> quite old, e.g. for brcm/brcmfmac4356-pcie.bin linux-firmware has:
> version 7.35.180.176 dated 2017-10-23, way before the CVE
> 
> Where as https://community.cypress.com/docs/DOC-19000 /
> cypress-fmac-v4.14.77-2020_0115.zip has:
> version 7.35.180.197 which presumably contains a fix (no changelog)

Ping?

The very old age of the firmware files in linux-firmware is really
UNACCEPTABLE and very irresponsible from a security POV. Please
fix this very soon.

If you do not reply to this email I see no choice but to switch
the firmwares in linux-firmware over to the ones from the SDK which
you do regularly update, e.g. those from:
https://community.cypress.com/docs/DOC-19000

Yes those are under an older, slightly different version of the Cypress
license, which is less then ideal, but that license is still acceptable
for linux-firmware (*) and since you are not providing any updates to
the special builds you have been doing for linux-firmware you are
really leaving us no option other then switching to the SDK version
of the firmwares.

Regards,

Hans

*) We have distributed files under the old version of the license before

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

[Hans de Goede]

Hi,

On 2/26/20 11:16 PM, Hans de Goede wrote:
> Hello Cypress people,
> 
> Can we please get updated firmware for
> brcm/brcmfmac4356-pcie.bin and brcm/brcmfmac4356-sdio.bin
> fixing CVE-2019-15126 as well as for any other affected
> models (the 4356 is explicitly named in the CVE description) ?
> 
> The current Cypress firmware files in linux-firmware are
> quite old, e.g. for brcm/brcmfmac4356-pcie.bin linux-firmware has:
> version 7.35.180.176 dated 2017-10-23, way before the CVE
> 
> Where as https://community.cypress.com/docs/DOC-19000 /
> cypress-fmac-v4.14.77-2020_0115.zip has:
> version 7.35.180.197 which presumably contains a fix (no changelog)

Ping?

The very old age of the firmware files in linux-firmware is really
UNACCEPTABLE and very irresponsible from a security POV. Please
fix this very soon.

If you do not reply to this email I see no choice but to switch
the firmwares in linux-firmware over to the ones from the SDK which
you do regularly update, e.g. those from:
https://community.cypress.com/docs/DOC-19000

Yes those are under an older, slightly different version of the Cypress
license, which is less then ideal, but that license is still acceptable
for linux-firmware (*) and since you are not providing any updates to
the special builds you have been doing for linux-firmware you are
really leaving us no option other then switching to the SDK version
of the firmwares.

Regards,

Hans

*) We have distributed files under the old version of the license before

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

[Chi-Hsien Lin]

(+Chris)

On 03/04/2020 7:45, Hans de Goede wrote:
> Hi,
> 
> On 2/26/20 11:16 PM, Hans de Goede wrote:
>> Hello Cypress people,
>>
>> Can we please get updated firmware for
>> brcm/brcmfmac4356-pcie.bin and brcm/brcmfmac4356-sdio.bin
>> fixing CVE-2019-15126 as well as for any other affected
>> models (the 4356 is explicitly named in the CVE description) ?
>>
>> The current Cypress firmware files in linux-firmware are
>> quite old, e.g. for brcm/brcmfmac4356-pcie.bin linux-firmware has:
>> version 7.35.180.176 dated 2017-10-23, way before the CVE
>>
>> Where as https://community.cypress.com/docs/DOC-19000 /
>> cypress-fmac-v4.14.77-2020_0115.zip has:
>> version 7.35.180.197 which presumably contains a fix (no changelog)
> 
> Ping?
> 
> The very old age of the firmware files in linux-firmware is really
> UNACCEPTABLE and very irresponsible from a security POV. Please
> fix this very soon.
> 
> If you do not reply to this email I see no choice but to switch
> the firmwares in linux-firmware over to the ones from the SDK which
> you do regularly update, e.g. those from:
> https://community.cypress.com/docs/DOC-19000
> 
> Yes those are under an older, slightly different version of the Cypress
> license, which is less then ideal, but that license is still acceptable
> for linux-firmware (*) and since you are not providing any updates to
> the special builds you have been doing for linux-firmware you are
> really leaving us no option other then switching to the SDK version
> of the firmwares.

Hans,

As we discussed previously, those files are not suitable for 
linux-firmware for the reason of regulatory (blobs are only for Cypress 
reference boards and could violate regulatory on other boards); also 
clm_blob download is not supported in kernels prior to 4.15 so those 
files won't work with older kernels.

Chris owns the Cypress firmware upstream strategy and will explain our 
going-forward strategy to you.


Regards,
Chi-hsien Lin


> 
> Regards,
> 
> Hans
> 
> *) We have distributed files under the old version of the license before
> 
> .
> 

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

[Chi-Hsien Lin]

(+Chris)

On 03/04/2020 7:45, Hans de Goede wrote:
> Hi,
> 
> On 2/26/20 11:16 PM, Hans de Goede wrote:
>> Hello Cypress people,
>>
>> Can we please get updated firmware for
>> brcm/brcmfmac4356-pcie.bin and brcm/brcmfmac4356-sdio.bin
>> fixing CVE-2019-15126 as well as for any other affected
>> models (the 4356 is explicitly named in the CVE description) ?
>>
>> The current Cypress firmware files in linux-firmware are
>> quite old, e.g. for brcm/brcmfmac4356-pcie.bin linux-firmware has:
>> version 7.35.180.176 dated 2017-10-23, way before the CVE
>>
>> Where as https://community.cypress.com/docs/DOC-19000 /
>> cypress-fmac-v4.14.77-2020_0115.zip has:
>> version 7.35.180.197 which presumably contains a fix (no changelog)
> 
> Ping?
> 
> The very old age of the firmware files in linux-firmware is really
> UNACCEPTABLE and very irresponsible from a security POV. Please
> fix this very soon.
> 
> If you do not reply to this email I see no choice but to switch
> the firmwares in linux-firmware over to the ones from the SDK which
> you do regularly update, e.g. those from:
> https://community.cypress.com/docs/DOC-19000
> 
> Yes those are under an older, slightly different version of the Cypress
> license, which is less then ideal, but that license is still acceptable
> for linux-firmware (*) and since you are not providing any updates to
> the special builds you have been doing for linux-firmware you are
> really leaving us no option other then switching to the SDK version
> of the firmwares.

Hans,

As we discussed previously, those files are not suitable for 
linux-firmware for the reason of regulatory (blobs are only for Cypress 
reference boards and could violate regulatory on other boards); also 
clm_blob download is not supported in kernels prior to 4.15 so those 
files won't work with older kernels.

Chris owns the Cypress firmware upstream strategy and will explain our 
going-forward strategy to you.


Regards,
Chi-hsien Lin


> 
> Regards,
> 
> Hans
> 
> *) We have distributed files under the old version of the license before
> 
> .
> 

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

[Hans de Goede]

Hi,

On 3/5/20 4:50 AM, Chi-Hsien Lin wrote:
> (+Chris)
> 
> On 03/04/2020 7:45, Hans de Goede wrote:
>> Hi,
>>
>> On 2/26/20 11:16 PM, Hans de Goede wrote:
>>> Hello Cypress people,
>>>
>>> Can we please get updated firmware for
>>> brcm/brcmfmac4356-pcie.bin and brcm/brcmfmac4356-sdio.bin
>>> fixing CVE-2019-15126 as well as for any other affected
>>> models (the 4356 is explicitly named in the CVE description) ?
>>>
>>> The current Cypress firmware files in linux-firmware are
>>> quite old, e.g. for brcm/brcmfmac4356-pcie.bin linux-firmware has:
>>> version 7.35.180.176 dated 2017-10-23, way before the CVE
>>>
>>> Where as https://community.cypress.com/docs/DOC-19000 /
>>> cypress-fmac-v4.14.77-2020_0115.zip has:
>>> version 7.35.180.197 which presumably contains a fix (no changelog)
>>
>> Ping?
>>
>> The very old age of the firmware files in linux-firmware is really
>> UNACCEPTABLE and very irresponsible from a security POV. Please
>> fix this very soon.
>>
>> If you do not reply to this email I see no choice but to switch
>> the firmwares in linux-firmware over to the ones from the SDK which
>> you do regularly update, e.g. those from:
>> https://community.cypress.com/docs/DOC-19000
>>
>> Yes those are under an older, slightly different version of the Cypress
>> license, which is less then ideal, but that license is still acceptable
>> for linux-firmware (*) and since you are not providing any updates to
>> the special builds you have been doing for linux-firmware you are
>> really leaving us no option other then switching to the SDK version
>> of the firmwares.
> 
> Hans,
> 
> As we discussed previously, those files are not suitable for linux-firmware for the reason of regulatory (blobs are only for Cypress reference boards and could violate regulatory on other boards);

But the special builds you are doing for Linux firmware have a clm_blob
too, the only difference is that it is embedded. If it is possible to
embed a generic version of the clm_blob, then why not provide separate
a generic version of the separate clm_blob files, so that those can be
used together with build which you release regularly as part of your
SDK ?

This way you do not need to do special builds for linux-firmware,
which seems to be the main bottleneck for having up2date Cypress
firmware files inside linux-firmware.

> 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. OTOH those are quite old kernels and if we
must choice between having recent firmware for modern kernels or old
kernel compatibility I guess the preference would be to have recent
firmware. Likely devices using such old kernels are not updating their
version of linux-firmware anyways.

> Chris owns the Cypress firmware upstream strategy and will explain our going-forward strategy to you.

Ok.

Regards,

Hans

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

[Hans de Goede]

Hi,

On 3/5/20 4:50 AM, Chi-Hsien Lin wrote:
> (+Chris)
> 
> On 03/04/2020 7:45, Hans de Goede wrote:
>> Hi,
>>
>> On 2/26/20 11:16 PM, Hans de Goede wrote:
>>> Hello Cypress people,
>>>
>>> Can we please get updated firmware for
>>> brcm/brcmfmac4356-pcie.bin and brcm/brcmfmac4356-sdio.bin
>>> fixing CVE-2019-15126 as well as for any other affected
>>> models (the 4356 is explicitly named in the CVE description) ?
>>>
>>> The current Cypress firmware files in linux-firmware are
>>> quite old, e.g. for brcm/brcmfmac4356-pcie.bin linux-firmware has:
>>> version 7.35.180.176 dated 2017-10-23, way before the CVE
>>>
>>> Where as https://community.cypress.com/docs/DOC-19000 /
>>> cypress-fmac-v4.14.77-2020_0115.zip has:
>>> version 7.35.180.197 which presumably contains a fix (no changelog)
>>
>> Ping?
>>
>> The very old age of the firmware files in linux-firmware is really
>> UNACCEPTABLE and very irresponsible from a security POV. Please
>> fix this very soon.
>>
>> If you do not reply to this email I see no choice but to switch
>> the firmwares in linux-firmware over to the ones from the SDK which
>> you do regularly update, e.g. those from:
>> https://community.cypress.com/docs/DOC-19000
>>
>> Yes those are under an older, slightly different version of the Cypress
>> license, which is less then ideal, but that license is still acceptable
>> for linux-firmware (*) and since you are not providing any updates to
>> the special builds you have been doing for linux-firmware you are
>> really leaving us no option other then switching to the SDK version
>> of the firmwares.
> 
> Hans,
> 
> As we discussed previously, those files are not suitable for linux-firmware for the reason of regulatory (blobs are only for Cypress reference boards and could violate regulatory on other boards);

But the special builds you are doing for Linux firmware have a clm_blob
too, the only difference is that it is embedded. If it is possible to
embed a generic version of the clm_blob, then why not provide separate
a generic version of the separate clm_blob files, so that those can be
used together with build which you release regularly as part of your
SDK ?

This way you do not need to do special builds for linux-firmware,
which seems to be the main bottleneck for having up2date Cypress
firmware files inside linux-firmware.

> 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. OTOH those are quite old kernels and if we
must choice between having recent firmware for modern kernels or old
kernel compatibility I guess the preference would be to have recent
firmware. Likely devices using such old kernels are not updating their
version of linux-firmware anyways.

> Chris owns the Cypress firmware upstream strategy and will explain our going-forward strategy to you.

Ok.

Regards,

Hans

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

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 959 bytes --]

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.


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5174 bytes --]

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

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 959 bytes --]

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.


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5174 bytes --]

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

[Hans de Goede]

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.

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

[Hans de Goede]

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.

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

[Chi-Hsien Lin]

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

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

[Chi-Hsien Lin]

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

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

[Hans de Goede]

Hi All,

On 2/26/20 11:16 PM, Hans de Goede wrote:
> Hello Cypress people,
> 
> Can we please get updated firmware for
> brcm/brcmfmac4356-pcie.bin and brcm/brcmfmac4356-sdio.bin
> fixing CVE-2019-15126 as well as for any other affected
> models (the 4356 is explicitly named in the CVE description) ?
> 
> The current Cypress firmware files in linux-firmware are
> quite old, e.g. for brcm/brcmfmac4356-pcie.bin linux-firmware has:
> version 7.35.180.176 dated 2017-10-23, way before the CVE
> 
> Where as https://community.cypress.com/docs/DOC-19000 /
> cypress-fmac-v4.14.77-2020_0115.zip has:
> version 7.35.180.197 which presumably contains a fix (no changelog)

Chris from Cypress has replied privately to me because of some
email issues, with the request to relay the information he
wrote here:

On 3/18/20 6:54 PM, Christopher Rumpf wrote:

 >  Cypress' CLM upstream policy is currently fragmented, as you have indicated.
 > The 43340 and 43362 have embedded CLM upstreamed yet no other Cypress parts
 > have done so and only deliver the firmware.bin files.  Cypress' customers
 > have been OK to follow this technote
 > https://www.cypress.com/documentation/application-notes/an225347-cypress-wi-fi-clm-regulatory-manual
 > which requires users to contact Cypress support to obtain the best performing
 > Country Locale Matrix (CLM) for the Wi-Fi module and targeted regions.
 > Such a model is of course not ideal for the open source community or for
 > what we  call “the broad market” as it requires an extra human to human
 > interaction that at the end of the day may reduce the user's time to
 > market and ability to independently move forward.
 >
 >  As I am sure you are aware, Cypress’ Embedded CLM = Wi-Fi Firmware +
 > regional regulatory database + RF settings (NVRAM).  The Wi-Fi Firmware is
 > static across all projects however the regional regulatory database and the
 > RF settings are implementation specific.  Previously the hesitation to
 > release a "worldwide generic embedded CLM” was because the regional
 > regulatory and RF settings are not tuned correctly for the implementation's
 > characteristics and the project may experience sub-par connectivity
 > performance or even perceived defects (such as power, RF, robustness).
 >
 > In the long term Cypress will be investing in additional tooling to automate
 > these steps, perhaps even as part of the project's config or build step.
 >
 > In the short term Cypress is considering these two actions:
 >
 > 1. For all active upstreamed Cypress parts, Cypress will upstream a
 >    "worldwide generic embedded CLM”.  These Embedded CLMs won’t be tuned for
 >    specific project’s regional or RF settings and customers may still need
 >    to reach out to Cypress support but at least they will be able to use the
 >    Cypress firmware in the linux-firmware repo right out of the box.

Note Chris later send me some clarification on this point:

On 3/18/20 10:29 PM, Christopher Rumpf wrote:
 > One clarification here! Regarding the short term solution -
 > the delivery may not be “embedded clm”.  It may be three different artifacts
 > which are meant to service the broad market. The Cypress R&D team will decide
 > the specifics of how to address the technical implementation to deliver the
 > worldwide clm.

The below is a continuation of Chris' original email:

 >  2. Cypress will add some more documentation in our READMEs and other
 >     supporting docs that discusses the risks which
 >     "worldwide generic embedded CLM” brings.  Customers can then make
 >     their own decision to engage with Cypress support which will depend
 >     on the characteristics of their project, I would imagine.
 >
 > Cypress would be able to implement these actions for the next release train
 > which will be posted somewhere around end of June (pending any impact due
 > to the coronavirus).
 >
 > Would these short and long term solutions meet the needs of the
 > linux-firmware community?  If no, may we collaborate more?

Chris, if I understand you correctly then the plan would result in the Cypress
maintained firmwares in linux-firmware being in sync (being the same versions
but with a more generic CLM) with the firmwares Cypress releases as part of
their SDK; and the first time we would see this in sync. release of Cypress
maintained firmwares would be around June. Correct?

This sounds very good to me.

I do have one question though, you describe the firmware as consisting of
3 parts: The actual firmware, the Country Locale Matrix and the NVRAM.

Currently linux-firmware contains firmwares with a generic CLM embedded
in them. But AFAIK the nvram-s are device-model/project specific (more so
then the CLM-s I believe) and normally the nvram is actual part of the
device and read by the kernel driver?  The one exception to this is the
nvram files for some SDIO boards. Recent kernels have code to load
the nvram files for these SDIO boards using a device-model specific
name and the linux-firmware repository contains community contributed
NVRAM files for various device-models. Would this change with the
new firmware versions ?

Regards,

Hans

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

[Hans de Goede]

Hi All,

On 2/26/20 11:16 PM, Hans de Goede wrote:
> Hello Cypress people,
> 
> Can we please get updated firmware for
> brcm/brcmfmac4356-pcie.bin and brcm/brcmfmac4356-sdio.bin
> fixing CVE-2019-15126 as well as for any other affected
> models (the 4356 is explicitly named in the CVE description) ?
> 
> The current Cypress firmware files in linux-firmware are
> quite old, e.g. for brcm/brcmfmac4356-pcie.bin linux-firmware has:
> version 7.35.180.176 dated 2017-10-23, way before the CVE
> 
> Where as https://community.cypress.com/docs/DOC-19000 /
> cypress-fmac-v4.14.77-2020_0115.zip has:
> version 7.35.180.197 which presumably contains a fix (no changelog)

Chris from Cypress has replied privately to me because of some
email issues, with the request to relay the information he
wrote here:

On 3/18/20 6:54 PM, Christopher Rumpf wrote:

 >  Cypress' CLM upstream policy is currently fragmented, as you have indicated.
 > The 43340 and 43362 have embedded CLM upstreamed yet no other Cypress parts
 > have done so and only deliver the firmware.bin files.  Cypress' customers
 > have been OK to follow this technote
 > https://www.cypress.com/documentation/application-notes/an225347-cypress-wi-fi-clm-regulatory-manual
 > which requires users to contact Cypress support to obtain the best performing
 > Country Locale Matrix (CLM) for the Wi-Fi module and targeted regions.
 > Such a model is of course not ideal for the open source community or for
 > what we  call “the broad market” as it requires an extra human to human
 > interaction that at the end of the day may reduce the user's time to
 > market and ability to independently move forward.
 >
 >  As I am sure you are aware, Cypress’ Embedded CLM = Wi-Fi Firmware +
 > regional regulatory database + RF settings (NVRAM).  The Wi-Fi Firmware is
 > static across all projects however the regional regulatory database and the
 > RF settings are implementation specific.  Previously the hesitation to
 > release a "worldwide generic embedded CLM” was because the regional
 > regulatory and RF settings are not tuned correctly for the implementation's
 > characteristics and the project may experience sub-par connectivity
 > performance or even perceived defects (such as power, RF, robustness).
 >
 > In the long term Cypress will be investing in additional tooling to automate
 > these steps, perhaps even as part of the project's config or build step.
 >
 > In the short term Cypress is considering these two actions:
 >
 > 1. For all active upstreamed Cypress parts, Cypress will upstream a
 >    "worldwide generic embedded CLM”.  These Embedded CLMs won’t be tuned for
 >    specific project’s regional or RF settings and customers may still need
 >    to reach out to Cypress support but at least they will be able to use the
 >    Cypress firmware in the linux-firmware repo right out of the box.

Note Chris later send me some clarification on this point:

On 3/18/20 10:29 PM, Christopher Rumpf wrote:
 > One clarification here! Regarding the short term solution -
 > the delivery may not be “embedded clm”.  It may be three different artifacts
 > which are meant to service the broad market. The Cypress R&D team will decide
 > the specifics of how to address the technical implementation to deliver the
 > worldwide clm.

The below is a continuation of Chris' original email:

 >  2. Cypress will add some more documentation in our READMEs and other
 >     supporting docs that discusses the risks which
 >     "worldwide generic embedded CLM” brings.  Customers can then make
 >     their own decision to engage with Cypress support which will depend
 >     on the characteristics of their project, I would imagine.
 >
 > Cypress would be able to implement these actions for the next release train
 > which will be posted somewhere around end of June (pending any impact due
 > to the coronavirus).
 >
 > Would these short and long term solutions meet the needs of the
 > linux-firmware community?  If no, may we collaborate more?

Chris, if I understand you correctly then the plan would result in the Cypress
maintained firmwares in linux-firmware being in sync (being the same versions
but with a more generic CLM) with the firmwares Cypress releases as part of
their SDK; and the first time we would see this in sync. release of Cypress
maintained firmwares would be around June. Correct?

This sounds very good to me.

I do have one question though, you describe the firmware as consisting of
3 parts: The actual firmware, the Country Locale Matrix and the NVRAM.

Currently linux-firmware contains firmwares with a generic CLM embedded
in them. But AFAIK the nvram-s are device-model/project specific (more so
then the CLM-s I believe) and normally the nvram is actual part of the
device and read by the kernel driver?  The one exception to this is the
nvram files for some SDIO boards. Recent kernels have code to load
the nvram files for these SDIO boards using a device-model specific
name and the linux-firmware repository contains community contributed
NVRAM files for various device-models. Would this change with the
new firmware versions ?

Regards,

Hans

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

[Hans de Goede]

Hi All,

Relaying Chris Rumpf's answer here again because of
his email issues:

On 3/18/20 11:06 PM, Hans de Goede wrote:
> Hi All,
> 
> On 2/26/20 11:16 PM, Hans de Goede wrote:
>> Hello Cypress people,
>>
>> Can we please get updated firmware for
>> brcm/brcmfmac4356-pcie.bin and brcm/brcmfmac4356-sdio.bin
>> fixing CVE-2019-15126 as well as for any other affected
>> models (the 4356 is explicitly named in the CVE description) ?
>>
>> The current Cypress firmware files in linux-firmware are
>> quite old, e.g. for brcm/brcmfmac4356-pcie.bin linux-firmware has:
>> version 7.35.180.176 dated 2017-10-23, way before the CVE
>>
>> Where as https://community.cypress.com/docs/DOC-19000 /
>> cypress-fmac-v4.14.77-2020_0115.zip has:
>> version 7.35.180.197 which presumably contains a fix (no changelog)
> 
> Chris from Cypress has replied privately to me because of some
> email issues, with the request to relay the information he
> wrote here:
> 
> On 3/18/20 6:54 PM, Christopher Rumpf wrote:
> 
>  >  Cypress' CLM upstream policy is currently fragmented, as you have indicated.
>  > The 43340 and 43362 have embedded CLM upstreamed yet no other Cypress parts
>  > have done so and only deliver the firmware.bin files.  Cypress' customers
>  > have been OK to follow this technote
>  > https://www.cypress.com/documentation/application-notes/an225347-cypress-wi-fi-clm-regulatory-manual
>  > which requires users to contact Cypress support to obtain the best performing
>  > Country Locale Matrix (CLM) for the Wi-Fi module and targeted regions.
>  > Such a model is of course not ideal for the open source community or for
>  > what we  call “the broad market” as it requires an extra human to human
>  > interaction that at the end of the day may reduce the user's time to
>  > market and ability to independently move forward.
>  >
>  >  As I am sure you are aware, Cypress’ Embedded CLM = Wi-Fi Firmware +
>  > regional regulatory database + RF settings (NVRAM).  The Wi-Fi Firmware is
>  > static across all projects however the regional regulatory database and the
>  > RF settings are implementation specific.  Previously the hesitation to
>  > release a "worldwide generic embedded CLM” was because the regional
>  > regulatory and RF settings are not tuned correctly for the implementation's
>  > characteristics and the project may experience sub-par connectivity
>  > performance or even perceived defects (such as power, RF, robustness).
>  >
>  > In the long term Cypress will be investing in additional tooling to automate
>  > these steps, perhaps even as part of the project's config or build step.
>  >
>  > In the short term Cypress is considering these two actions:
>  >
>  > 1. For all active upstreamed Cypress parts, Cypress will upstream a
>  >    "worldwide generic embedded CLM”.  These Embedded CLMs won’t be tuned for
>  >    specific project’s regional or RF settings and customers may still need
>  >    to reach out to Cypress support but at least they will be able to use the
>  >    Cypress firmware in the linux-firmware repo right out of the box.
> 
> Note Chris later send me some clarification on this point:
> 
> On 3/18/20 10:29 PM, Christopher Rumpf wrote:
>  > One clarification here! Regarding the short term solution -
>  > the delivery may not be “embedded clm”.  It may be three different artifacts
>  > which are meant to service the broad market. The Cypress R&D team will decide
>  > the specifics of how to address the technical implementation to deliver the
>  > worldwide clm.
> 
> The below is a continuation of Chris' original email:
> 
>  >  2. Cypress will add some more documentation in our READMEs and other
>  >     supporting docs that discusses the risks which
>  >     "worldwide generic embedded CLM” brings.  Customers can then make
>  >     their own decision to engage with Cypress support which will depend
>  >     on the characteristics of their project, I would imagine.
>  >
>  > Cypress would be able to implement these actions for the next release train
>  > which will be posted somewhere around end of June (pending any impact due
>  > to the coronavirus).
>  >
>  > Would these short and long term solutions meet the needs of the
>  > linux-firmware community?  If no, may we collaborate more?
> 
> Chris, if I understand you correctly then the plan would result in the Cypress
> maintained firmwares in linux-firmware being in sync (being the same versions
> but with a more generic CLM) with the firmwares Cypress releases as part of
> their SDK; and the first time we would see this in sync. release of Cypress
> maintained firmwares would be around June. Correct?

On 3/18/20 11:19 PM, Christopher Rumpf wrote:

The understanding of the solution and the timeline is correct.

> This sounds very good to me.
> 
> I do have one question though, you describe the firmware as consisting of
> 3 parts: The actual firmware, the Country Locale Matrix and the NVRAM.
> 
> Currently linux-firmware contains firmwares with a generic CLM embedded
> in them. But AFAIK the nvram-s are device-model/project specific (more so
> then the CLM-s I believe) and normally the nvram is actual part of the
> device and read by the kernel driver?  The one exception to this is the
> nvram files for some SDIO boards. Recent kernels have code to load
> the nvram files for these SDIO boards using a device-model specific
> name and the linux-firmware repository contains community contributed
> NVRAM files for various device-models. Would this change with the
> new firmware versions ?

On 3/18/20 11:19 PM, Christopher Rumpf wrote:

No changes here.  My bad, I probably should have written this:
 > Cypress’ Embedded CLM = Wi-Fi Firmware + regional regulatory database + RF settings (NVRAM).
as
Cypress’ Solution = Wi-Fi Firmware + regional regulatory database (CLM) + RF settings (NVRAM).

The idea/architecture here is to allow for these software parts to change
independently. So yes, users can change nvram (or CLM or the firmware itself)
and still use the overall solution.

Regards,

Hans

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

[Hans de Goede]

Hi All,

Relaying Chris Rumpf's answer here again because of
his email issues:

On 3/18/20 11:06 PM, Hans de Goede wrote:
> Hi All,
> 
> On 2/26/20 11:16 PM, Hans de Goede wrote:
>> Hello Cypress people,
>>
>> Can we please get updated firmware for
>> brcm/brcmfmac4356-pcie.bin and brcm/brcmfmac4356-sdio.bin
>> fixing CVE-2019-15126 as well as for any other affected
>> models (the 4356 is explicitly named in the CVE description) ?
>>
>> The current Cypress firmware files in linux-firmware are
>> quite old, e.g. for brcm/brcmfmac4356-pcie.bin linux-firmware has:
>> version 7.35.180.176 dated 2017-10-23, way before the CVE
>>
>> Where as https://community.cypress.com/docs/DOC-19000 /
>> cypress-fmac-v4.14.77-2020_0115.zip has:
>> version 7.35.180.197 which presumably contains a fix (no changelog)
> 
> Chris from Cypress has replied privately to me because of some
> email issues, with the request to relay the information he
> wrote here:
> 
> On 3/18/20 6:54 PM, Christopher Rumpf wrote:
> 
>  >  Cypress' CLM upstream policy is currently fragmented, as you have indicated.
>  > The 43340 and 43362 have embedded CLM upstreamed yet no other Cypress parts
>  > have done so and only deliver the firmware.bin files.  Cypress' customers
>  > have been OK to follow this technote
>  > https://www.cypress.com/documentation/application-notes/an225347-cypress-wi-fi-clm-regulatory-manual
>  > which requires users to contact Cypress support to obtain the best performing
>  > Country Locale Matrix (CLM) for the Wi-Fi module and targeted regions.
>  > Such a model is of course not ideal for the open source community or for
>  > what we  call “the broad market” as it requires an extra human to human
>  > interaction that at the end of the day may reduce the user's time to
>  > market and ability to independently move forward.
>  >
>  >  As I am sure you are aware, Cypress’ Embedded CLM = Wi-Fi Firmware +
>  > regional regulatory database + RF settings (NVRAM).  The Wi-Fi Firmware is
>  > static across all projects however the regional regulatory database and the
>  > RF settings are implementation specific.  Previously the hesitation to
>  > release a "worldwide generic embedded CLM” was because the regional
>  > regulatory and RF settings are not tuned correctly for the implementation's
>  > characteristics and the project may experience sub-par connectivity
>  > performance or even perceived defects (such as power, RF, robustness).
>  >
>  > In the long term Cypress will be investing in additional tooling to automate
>  > these steps, perhaps even as part of the project's config or build step.
>  >
>  > In the short term Cypress is considering these two actions:
>  >
>  > 1. For all active upstreamed Cypress parts, Cypress will upstream a
>  >    "worldwide generic embedded CLM”.  These Embedded CLMs won’t be tuned for
>  >    specific project’s regional or RF settings and customers may still need
>  >    to reach out to Cypress support but at least they will be able to use the
>  >    Cypress firmware in the linux-firmware repo right out of the box.
> 
> Note Chris later send me some clarification on this point:
> 
> On 3/18/20 10:29 PM, Christopher Rumpf wrote:
>  > One clarification here! Regarding the short term solution -
>  > the delivery may not be “embedded clm”.  It may be three different artifacts
>  > which are meant to service the broad market. The Cypress R&D team will decide
>  > the specifics of how to address the technical implementation to deliver the
>  > worldwide clm.
> 
> The below is a continuation of Chris' original email:
> 
>  >  2. Cypress will add some more documentation in our READMEs and other
>  >     supporting docs that discusses the risks which
>  >     "worldwide generic embedded CLM” brings.  Customers can then make
>  >     their own decision to engage with Cypress support which will depend
>  >     on the characteristics of their project, I would imagine.
>  >
>  > Cypress would be able to implement these actions for the next release train
>  > which will be posted somewhere around end of June (pending any impact due
>  > to the coronavirus).
>  >
>  > Would these short and long term solutions meet the needs of the
>  > linux-firmware community?  If no, may we collaborate more?
> 
> Chris, if I understand you correctly then the plan would result in the Cypress
> maintained firmwares in linux-firmware being in sync (being the same versions
> but with a more generic CLM) with the firmwares Cypress releases as part of
> their SDK; and the first time we would see this in sync. release of Cypress
> maintained firmwares would be around June. Correct?

On 3/18/20 11:19 PM, Christopher Rumpf wrote:

The understanding of the solution and the timeline is correct.

> This sounds very good to me.
> 
> I do have one question though, you describe the firmware as consisting of
> 3 parts: The actual firmware, the Country Locale Matrix and the NVRAM.
> 
> Currently linux-firmware contains firmwares with a generic CLM embedded
> in them. But AFAIK the nvram-s are device-model/project specific (more so
> then the CLM-s I believe) and normally the nvram is actual part of the
> device and read by the kernel driver?  The one exception to this is the
> nvram files for some SDIO boards. Recent kernels have code to load
> the nvram files for these SDIO boards using a device-model specific
> name and the linux-firmware repository contains community contributed
> NVRAM files for various device-models. Would this change with the
> new firmware versions ?

On 3/18/20 11:19 PM, Christopher Rumpf wrote:

No changes here.  My bad, I probably should have written this:
 > Cypress’ Embedded CLM = Wi-Fi Firmware + regional regulatory database + RF settings (NVRAM).
as
Cypress’ Solution = Wi-Fi Firmware + regional regulatory database (CLM) + RF settings (NVRAM).

The idea/architecture here is to allow for these software parts to change
independently. So yes, users can change nvram (or CLM or the firmware itself)
and still use the overall solution.

Regards,

Hans