linux-firmware.lore.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: chi-hsien.lin@cypress.com,
	Christopher Rumpf <Christopher.Rumpf@cypress.com>,
	Chung-Hsien Hsu <cnhu@cypress.com>
Cc: linux-firmware@kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Updating cypress/brcm firmware in linux-firmware for CVE-2019-15126
Date: Thu, 5 Mar 2020 07:24:44 +0100	[thread overview]
Message-ID: <17ec344e-80c5-02a9-59a3-35789a2eaaf9@redhat.com> (raw)
In-Reply-To: <3cf961a6-56c8-81fb-3bf9-fc36e2601d2c@cypress.com>

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


  parent reply	other threads:[~2020-03-05  6:24 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-26 22:16 Updating cypress/brcm firmware in linux-firmware for CVE-2019-15126 Hans de Goede
2020-02-26 22:16 ` Hans de Goede
2020-03-04 11:45 ` Hans de Goede
2020-03-04 11:45   ` Hans de Goede
2020-03-05  3:50   ` Chi-Hsien Lin
2020-03-05  3:50     ` Chi-Hsien Lin
2020-03-05  6:24     ` Hans de Goede [this message]
2020-03-05  6:24       ` Hans de Goede
2020-03-05  9:16       ` David Woodhouse
2020-03-05  9:16         ` David Woodhouse
2020-03-05 14:00         ` Hans de Goede
2020-03-05 14:00           ` Hans de Goede
2020-03-06  9:58           ` Chi-Hsien Lin
2020-03-06  9:58             ` Chi-Hsien Lin
2020-03-18 22:06 ` Hans de Goede
2020-03-18 22:06   ` Hans de Goede
2020-03-19 12:41   ` Hans de Goede
2020-03-19 12:41     ` Hans de Goede

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=17ec344e-80c5-02a9-59a3-35789a2eaaf9@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=Christopher.Rumpf@cypress.com \
    --cc=chi-hsien.lin@cypress.com \
    --cc=cnhu@cypress.com \
    --cc=linux-firmware@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
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).