Alpine's linux-firmware package pulls from the upstream linux-firmware repo: the Wi-Fi drivers available there are very old. For example, the BCM4358 firmware available there was built in September 2016 and is vulnerable to Broadpwn. This is a problem as four devices use the outdated linux-firmware blobs.
Should we use manufacturer Wi-Fi firmware or AOSP firmware if they are newer, or somehow get Broadcom to release updated Wi-Fi drivers to the linux-firmware repo?
linux-firmware - is it OK when I do it like that, or would you prefer to be notified in another way?)@ncopa: How does Alpine handle this issue, would you guys consider "patching" (using another blob) in the linux-firmware package?
@zhuowei: For postmarketOS, we can use any source (e.g. AOSP like you have linked) for firmware instead in case we need Broadcom firmware.
Of course this should also be fixed upstream in the kernel. I recommend to do some research first - has this been discussed on the Linux kernel mailing list already? Who is the responsible person for the drivers in the kernel (as the kernel has maintainers for everything)? - Then either joining the discussion on the LKML or starting a new one/writing the maintainer. I am not involved in kernel development though, this is how I think it should be done with my limited knowledge from an outside view.
Thank you for pointing this out! I would appreciate it very much if you tried to get this fixed in the kernel (and of course also in pmOS depending on how it is handled in Alpine, ideally we can continue using the Alpine package or even help our upstream friends resolve it!).
@ollieparanoid I emailed the Broadcom employee that originally uploaded the BCM4358 firmware, about updating the firmware in the linux-firmware repository, and he replied that
Some wifi chips are end-of-life meaning that we do no longer support
them. The bcm4358 that you refer to is still supported and we plan to
provide a new version for it and some other chips.
So some of the newer devices may receive newer firmware in the upstream repo eventually.
It's nice of him that he answered you so fast! Maybe it makes sense to use this pre-release, that also fixes broadpwn, in the meantime. The Raspberry Pi 3 is also affected, as that ticket shows.
@zhuowei: I guess you need the broadcom driver for your device? If so, I would suggest you try out that inofficial version with the fix.
I would prefer that this gets reported to the upstream linux-firmware maintainers so they can update that.
@ncopa: after reading the README of the linux-firmware repository, I doubt that there is much more that we can do to get it fixed upstream, except for nicely ask a Broadcom employee to upload a fixed version (which is what @zhuowei already did, see above):
Being redistributable includes ensuring the firmware license provided includes an implicit or explicit
patent grant to end users to ensure full functionality of device operation with the firmware.
With that inofficial version available for testing, there won't be such a functionallity grant. But please tell me if I'm missing something here.
@ollieparanoid The Nexus 6P's stock firmware uses a blob from AOSP; should I use that instead of linux-firmware's blob?
Yep, that must be newer and should have the broadpwn security holes fixed, so please use that instead.
Seems like a group has also created some aftermarket firmware patches for BCM4358 as well as other vulnerable chipsets like BCM4339 (used in the Galaxy Nexus). They seem to fix broadpwn and add some more features (e.g. monitor mode).
Do you think it would be a good idea to get this packaged for postmarketOS?
@Pneumaticat: excellent find! Yes, we should get that packaged, as it really allows to patch firmware that is not supported by upstream anymore \o/ we should look out to avoid their data collection though.
EDIT: After looking through it some more, they don't seem to patch broadpwn yet, but it should be possible. Really great work they did there, I thought there was no way we could ever change the (wifi) firmware, yet here we are. -- So for this discussion I guess the best way for now for postmarketOS is using the AOSP firmware for devices still supported by Broadcom until the drivers are updated in linux-firmware. Nexmon will be very handy in the future when they manage to fix CVEs in firmwares (maybe some of us can support them?).
Actually, I think at least _some_ chipsets have been patched -- https://github.com/seemoo-lab/nexmon/tree/master/patches/bcm4339/6_37_34_43/anti_broadpwn for example has a patchset that tries to fix it. It calls it a first try, and I'm not familiar with the details of the exploit, but it might be worth having.
Nexmon as a whole also has some pretty sweet monitor mode patches which could be fun if packaged -- wardriving on postmarketOS? ;)
I'm closing this issue. Alpine's linux-firmware did actually have the unofficial Pi firmware fix packaged (https://github.com/postmarketOS/pmbootstrap/issues/513#issuecomment-327266718).
We need to look into patching wifi firmware with nexmon in general, so we can also patch out all the other issues though.
Some wifi chips are end-of-life meaning that we do no longer support them.
I'm not sure @arend really got the point of the issue.
It's not really about "please fix such and such bugs".
But: please put this update you *already* released into "official" repo.
And even though I have seen he delivered this fall, for the love of me I still cannot understand why a still-not-up-to-date version was choosen.
I noted such oddity even with a lot of other chipsets.