[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <17ec344e-80c5-02a9-59a3-35789a2eaaf9@redhat.com>
Date: Thu, 5 Mar 2020 07:24:44 +0100
From: Hans de Goede <hdegoede@...hat.com>
To: chi-hsien.lin@...ress.com,
Christopher Rumpf <Christopher.Rumpf@...ress.com>,
Chung-Hsien Hsu <cnhu@...ress.com>
Cc: linux-firmware@...nel.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Updating cypress/brcm firmware in linux-firmware for
CVE-2019-15126
Hi,
On 3/5/20 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
Powered by blists - more mailing lists