* Updating cypress/brcm firmware in linux-firmware for CVE-2019-15126 @ 2020-02-26 22:16 Hans de Goede 2020-03-04 11:45 ` Hans de Goede 2020-03-18 22:06 ` Hans de Goede 0 siblings, 2 replies; 10+ messages in thread From: Hans de Goede @ 2020-02-26 22:16 UTC (permalink / raw) To: Chi-Hsien Lin, Chirjeev Singh, Chung-Hsien Hsu Cc: linux-firmware, Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Updating cypress/brcm firmware in linux-firmware for CVE-2019-15126 2020-02-26 22:16 Updating cypress/brcm firmware in linux-firmware for CVE-2019-15126 Hans de Goede @ 2020-03-04 11:45 ` Hans de Goede 2020-03-05 3:50 ` Chi-Hsien Lin 2020-03-18 22:06 ` Hans de Goede 1 sibling, 1 reply; 10+ messages in thread From: Hans de Goede @ 2020-03-04 11:45 UTC (permalink / raw) To: Chi-Hsien Lin, Chirjeev Singh, Chung-Hsien Hsu Cc: linux-firmware, Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Updating cypress/brcm firmware in linux-firmware for CVE-2019-15126 2020-03-04 11:45 ` Hans de Goede @ 2020-03-05 3:50 ` Chi-Hsien Lin 2020-03-05 6:24 ` Hans de Goede 2020-03-11 16:34 ` Hans de Goede 0 siblings, 2 replies; 10+ messages in thread From: Chi-Hsien Lin @ 2020-03-05 3:50 UTC (permalink / raw) To: Hans de Goede, Christopher Rumpf, Chung-Hsien Hsu Cc: linux-firmware, Linux Kernel Mailing List (+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 > > . > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Updating cypress/brcm firmware in linux-firmware for CVE-2019-15126 2020-03-05 3:50 ` Chi-Hsien Lin @ 2020-03-05 6:24 ` Hans de Goede 2020-03-05 9:16 ` David Woodhouse 2020-03-11 16:34 ` Hans de Goede 1 sibling, 1 reply; 10+ messages in thread From: Hans de Goede @ 2020-03-05 6:24 UTC (permalink / raw) To: chi-hsien.lin, Christopher Rumpf, Chung-Hsien Hsu Cc: linux-firmware, Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Updating cypress/brcm firmware in linux-firmware for CVE-2019-15126 2020-03-05 6:24 ` Hans de Goede @ 2020-03-05 9:16 ` David Woodhouse 2020-03-05 14:00 ` Hans de Goede 0 siblings, 1 reply; 10+ messages in thread From: David Woodhouse @ 2020-03-05 9:16 UTC (permalink / raw) To: Hans de Goede, chi-hsien.lin, Christopher Rumpf, Chung-Hsien Hsu Cc: linux-firmware, Linux Kernel Mailing List [-- 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 --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Updating cypress/brcm firmware in linux-firmware for CVE-2019-15126 2020-03-05 9:16 ` David Woodhouse @ 2020-03-05 14:00 ` Hans de Goede 2020-03-06 9:58 ` Chi-Hsien Lin 0 siblings, 1 reply; 10+ messages in thread From: Hans de Goede @ 2020-03-05 14:00 UTC (permalink / raw) To: David Woodhouse, chi-hsien.lin, Christopher Rumpf, Chung-Hsien Hsu Cc: linux-firmware, Linux Kernel Mailing List 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Updating cypress/brcm firmware in linux-firmware for CVE-2019-15126 2020-03-05 14:00 ` Hans de Goede @ 2020-03-06 9:58 ` Chi-Hsien Lin 0 siblings, 0 replies; 10+ messages in thread From: Chi-Hsien Lin @ 2020-03-06 9:58 UTC (permalink / raw) To: Hans de Goede, David Woodhouse, Christopher Rumpf, Chung-Hsien Hsu Cc: linux-firmware, Linux Kernel Mailing List 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. > > > > > . > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Updating cypress/brcm firmware in linux-firmware for CVE-2019-15126 2020-03-05 3:50 ` Chi-Hsien Lin 2020-03-05 6:24 ` Hans de Goede @ 2020-03-11 16:34 ` Hans de Goede 1 sibling, 0 replies; 10+ messages in thread From: Hans de Goede @ 2020-03-11 16:34 UTC (permalink / raw) To: chi-hsien.lin, Christopher Rumpf, Chung-Hsien Hsu Cc: linux-firmware, Linux Kernel Mailing List 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, <snip> > Chris owns the Cypress firmware upstream strategy and will explain our going-forward strategy to you. Ping? It has been a week and we have not heard anything from Chris about this yet? Regards, Hans ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Updating cypress/brcm firmware in linux-firmware for CVE-2019-15126 2020-02-26 22:16 Updating cypress/brcm firmware in linux-firmware for CVE-2019-15126 Hans de Goede 2020-03-04 11:45 ` Hans de Goede @ 2020-03-18 22:06 ` Hans de Goede 2020-03-19 12:41 ` Hans de Goede 1 sibling, 1 reply; 10+ messages in thread From: Hans de Goede @ 2020-03-18 22:06 UTC (permalink / raw) To: Chi-Hsien Lin, Chirjeev Singh, Chung-Hsien Hsu, Christopher Rumpf Cc: linux-firmware, Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Updating cypress/brcm firmware in linux-firmware for CVE-2019-15126 2020-03-18 22:06 ` Hans de Goede @ 2020-03-19 12:41 ` Hans de Goede 0 siblings, 0 replies; 10+ messages in thread From: Hans de Goede @ 2020-03-19 12:41 UTC (permalink / raw) To: Chi-Hsien Lin, Chung-Hsien Hsu, Christopher Rumpf Cc: linux-firmware, Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2020-03-19 12:42 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-02-26 22:16 Updating cypress/brcm firmware in linux-firmware for CVE-2019-15126 Hans de Goede 2020-03-04 11:45 ` Hans de Goede 2020-03-05 3:50 ` Chi-Hsien Lin 2020-03-05 6:24 ` Hans de Goede 2020-03-05 9:16 ` David Woodhouse 2020-03-05 14:00 ` Hans de Goede 2020-03-06 9:58 ` Chi-Hsien Lin 2020-03-11 16:34 ` Hans de Goede 2020-03-18 22:06 ` Hans de Goede 2020-03-19 12:41 ` Hans de Goede
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).