Re: Question to recent Qualcomm CVEs
Robert Marko writes: > On Tue, 30 Apr 2024 at 10:48, Kalle Valo wrote: > >> >> Robert Marko writes: >> >> > On Mon, 29 Apr 2024 at 15:37, Sven Eckelmann wrote: >> >> >> >> On Monday, 29 April 2024 15:14:18 CEST Kalle Valo wrote: >> >> > It's quite strange that they updated 2.5.0.1 branch first but my >> >> > understanding that there should be updates for the newer 2.7.0.1 branch >> >> > as well (2.7.0.1 branch is also in linux-firmware). >> >> >> >> Yes, I also told them in the support ticket that this is from an older >> >> branch >> >> than what is currently shipped in linux-firmware.git. But they told me >> >> that they are working on newer versions (whatever that means) - but they >> >> wanted to handle first the update to ATH.11.4 (2.5.0.x) and then >> >> step-by-step release it for newer firmware branches. It seem like that >> >> would be >> >> up to 2.9.0.x - no idea why there is no (public) 2.10.x/2.11.x for the AP >> >> SoCs. >> > >> > I would like to point out that IPQ6018 doesn't even have anything >> > newer than 2.5.0.1 available publicly. >> >> But I do see WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1 for IPQ6018: >> >> https://git.codelinaro.org/clo/ath-firmware/ath11k-firmware/-/tree/main/IPQ6018/hw1.0/2.7.0.1/WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1?ref_type=heads >> >> And that release seems to be also in linux-firmware: >> >> File: ath11k/IPQ6018/hw1.0/q6_fw.mdt >> Version: WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1 >> >> Am I missing something? Or did you mean IPQ5018 which only has a release >> from 2.6.0.1 branch? >> >> https://git.codelinaro.org/clo/ath-firmware/ath11k-firmware/-/tree/main/IPQ5018/hw1.0?ref_type=heads > > Ah yes, sorry for the confusion, I meant to say newer than 2.5.0.1 > that actually works. > All of the newer public FW than 2.5.0.1 that we tried in OpenWrt will > just crash, we had the same issue with 2.6 and 2.7 FW on > IPQ8074 and it was fixed in 2.9.0.1 but there is no 2.9.0.1 public for > IPQ6018. Ah, is the issue you are talking about this bug: https://bugzilla.kernel.org/show_bug.cgi?id=216515 Or is this another issue? -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Question to recent Qualcomm CVEs
Robert Marko writes: > On Mon, 29 Apr 2024 at 15:37, Sven Eckelmann wrote: >> >> On Monday, 29 April 2024 15:14:18 CEST Kalle Valo wrote: >> > It's quite strange that they updated 2.5.0.1 branch first but my >> > understanding that there should be updates for the newer 2.7.0.1 branch >> > as well (2.7.0.1 branch is also in linux-firmware). >> >> Yes, I also told them in the support ticket that this is from an older branch >> than what is currently shipped in linux-firmware.git. But they told me >> that they are working on newer versions (whatever that means) - but they >> wanted to handle first the update to ATH.11.4 (2.5.0.x) and then >> step-by-step release it for newer firmware branches. It seem like that would >> be >> up to 2.9.0.x - no idea why there is no (public) 2.10.x/2.11.x for the AP >> SoCs. > > I would like to point out that IPQ6018 doesn't even have anything > newer than 2.5.0.1 available publicly. But I do see WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1 for IPQ6018: https://git.codelinaro.org/clo/ath-firmware/ath11k-firmware/-/tree/main/IPQ6018/hw1.0/2.7.0.1/WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1?ref_type=heads And that release seems to be also in linux-firmware: File: ath11k/IPQ6018/hw1.0/q6_fw.mdt Version: WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1 Am I missing something? Or did you mean IPQ5018 which only has a release from 2.6.0.1 branch? https://git.codelinaro.org/clo/ath-firmware/ath11k-firmware/-/tree/main/IPQ5018/hw1.0?ref_type=heads -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Question to recent Qualcomm CVEs
Kalle Valo writes: > + ath11k, jeff > > Sven Eckelmann writes: > >> On Monday, 26 February 2024 15:50:44 CET Felix Fietkau wrote: >> [...] >>>> The Qualcomm bulletin[1] says "Patches are being actively >>> > shared with OEMs". >>> > >>> > Were these bugfixes made available for OpenWRT? Is there an established >>> > procedure for such cases, where closed-source firmware gets bugfixes? >> [...] >>> > [1] >>> > https://docs.qualcomm.com/product/publicresources/securitybulletin/ >> december-2023-bulletin.html >>> >>> The fixes were not shared with OpenWrt. Qualcomm does not care about >>> OpenWrt support for their platforms. >> >> I've asked (using their qualcomm-cdmatech-support portal) for an official >> release of their WiFi firmware with all gathered bugfixes via >> linux-firmware.git. I got statements that the ath10k firmware is no longer >> supported + ath11k firmware is not developed further. But for some of them >> it >> is possible to request a release of the firmwares via Kalle's repositories. >> But also that Kalle's repositories are now replaced. Which seems to be >> confirmed by Kalle's statement [1] regarding the firmware-N.bin files on >> ath...@lists.infradead.org . >> >> The new positions for firmware files were not revealed but I found a couple >> of >> places [2,3,4,5] in my search. > > Yeah, the ath1?k-firmware.git repos are being moved to > git.codelinaro.org and we will send an announcement once everything is > ready. > >> And to the request to get the latest versions released via >> linux-firmware.git >> (or maybe even only in Kalle's repositories), I got (some weeks ago) the >> answer "Let me check with our team.". >> >> It is rather hard to make statements about Qualcomm - simply because it is >> not just a single person and I have no idea about the internal structures. >> But >> it doesn't seem to be the highest priority (for the "internal team"?) to >> make >> fixes available for everyone. I still hope that it is just delayed due to >> some >> unfortunate circumstances. But this is just the current state. > > Thanks for letting me know, I was not aware any of this. Me and Jeff > will investigate and get back to you. In case not everyone noticed but Jeff has now uploaded updates to 2.5.0.1 branch: https://git.codelinaro.org/clo/ath-firmware/ath11k-firmware/-/commit/97e0d33fe3e0f708459a682b167014906719337d https://git.codelinaro.org/clo/ath-firmware/ath11k-firmware/-/commit/04dd351414737ac14b3e381d3695b59f4de67eaa https://git.codelinaro.org/clo/ath-firmware/ath11k-firmware/-/commit/2dda8ce67f65af54f86fb2f49316174841fa95f7 It's quite strange that they updated 2.5.0.1 branch first but my understanding that there should be updates for the newer 2.7.0.1 branch as well (2.7.0.1 branch is also in linux-firmware). -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Question to recent Qualcomm CVEs
+ ath11k, jeff Sven Eckelmann writes: > On Monday, 26 February 2024 15:50:44 CET Felix Fietkau wrote: > [...] >>> The Qualcomm bulletin[1] says "Patches are being actively >> > shared with OEMs". >> > >> > Were these bugfixes made available for OpenWRT? Is there an established >> > procedure for such cases, where closed-source firmware gets bugfixes? > [...] >> > [1] >> > https://docs.qualcomm.com/product/publicresources/securitybulletin/ > december-2023-bulletin.html >> >> The fixes were not shared with OpenWrt. Qualcomm does not care about >> OpenWrt support for their platforms. > > I've asked (using their qualcomm-cdmatech-support portal) for an official > release of their WiFi firmware with all gathered bugfixes via > linux-firmware.git. I got statements that the ath10k firmware is no longer > supported + ath11k firmware is not developed further. But for some of them it > is possible to request a release of the firmwares via Kalle's repositories. > But also that Kalle's repositories are now replaced. Which seems to be > confirmed by Kalle's statement [1] regarding the firmware-N.bin files on > ath...@lists.infradead.org . > > The new positions for firmware files were not revealed but I found a couple > of > places [2,3,4,5] in my search. Yeah, the ath1?k-firmware.git repos are being moved to git.codelinaro.org and we will send an announcement once everything is ready. > And to the request to get the latest versions released via linux-firmware.git > (or maybe even only in Kalle's repositories), I got (some weeks ago) the > answer "Let me check with our team.". > > It is rather hard to make statements about Qualcomm - simply because it is > not just a single person and I have no idea about the internal structures. > But > it doesn't seem to be the highest priority (for the "internal team"?) to make > fixes available for everyone. I still hope that it is just delayed due to > some > unfortunate circumstances. But this is just the current state. Thanks for letting me know, I was not aware any of this. Me and Jeff will investigate and get back to you. For others, here's a link to the thread in openwrt-devel: https://lists.openwrt.org/pipermail/openwrt-devel/2024-February/042341.html -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: CVE-2020-3702: Firmware updates for ath9k and ath10k chips
Baptiste Jonglez writes:
> Hi,
>
> Cross-posting to openwrt-devel because we are backporting the necessary fixes.
>
> On 12-08-20, Jouni Malinen wrote:
>> On Wed, Aug 12, 2020 at 11:17:47AM +0200, Toke H?iland-J?rgensen wrote:
>> > Pali Roh?r writes:
>> > > Could somebody react and provide some details when fixes would be
>> > > available for ath9k and ath10k Linux drivers? And what is current state
>> > > of this issue for Linux?
>> > >
>> > > I'm looking at ath9k and ath10k git trees [1] [2] [3] and I do not see
>> > > there any change which could be related to CVE-2020-3702.
>> >
>> > How about these, from March:
>> >
>> > a0761a301746 ("mac80211: drop data frames without key on encrypted links")
>> > ce2e1ca70307 ("mac80211: Check port authorization in the
>> > ieee80211_tx_dequeue() case")
>> > b16798f5b907 ("mac80211: mark station unauthorized before key removal")
>>
>> Those cover most of the identified issues for drivers using mac80211
>> (e.g., ath9k and ath10k; though, I don't remember whether I actually
>> ever managed to reproduce this with ath10k in practice). I have couple
>> of additional ath9k-specific patches that cover additional lower layer
>> paths for this. I hope to get those out after confirming they work with
>> the current kernel tree snapshot.
>
> I could find linux-stable backports for ce2e1ca70307 and b16798f5b907, but
> not for a0761a301746. Is it intended? From the commit message, it looks
> like it does fix an important issue.
>
> Also, for the sake of completeness, this subsequent commit is also related
> to CVE-2020-3702 (and already backported):
>
> 5981fe5b0529 ("mac80211: fix misplaced while instead of if")
I think you should ask the stable to also take commit a0761a301746, most
likely they just missed it by accident.
--
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v13] ath10k: add LED and GPIO controlling support for various chipsets
Sven Eckelmann writes:
> On Monday, 25 May 2020 11:22:13 CEST Sven Eckelmann wrote:
> [...]
>> And it still can with this OpenWrt version. But it doesn't seem to happen
>> with
>> the most recent OpenWrt reboot-13353-gb1604b744b. But there are nearly 4000
>> commits inbetween. So no idea what changed (just a timing thing or an actual
>> fix - no idea).
>
> Seems like there is a fix which solves some lost interrupt problems for
> IPQ40xx. Without this change, I see the reported problem. And with the patch,
> it is gone. Or in commits:
>
> * creates timeout problems: 46b949a067e5 ("ipq40xx: enlarge PCIe BAR size")
> * works fine: 18e942b6c4e5 ("ipq40xx: fix pcie msi IRQ trigger level")
>
> If you look in the git logs [1], you can see that the working commit is a
> child of the broken one. So at least from my point of view, my initial report
> is no blocker anymore for Sebastian's patch (or Kalle's version of it).
Great. If the patch is good to take can someone rebase the latest
version and resubmit, please?
--
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v13] ath10k: add LED and GPIO controlling support for various chipsets
(please don't top post) Sebastian Gottschall writes: > this code is not in use in its original form for ipq4019. i have seen > that his patch is also dropped from ath.git but is still in use by > openwrt. could somone clarify the state here and why it was dropped? I dropped the patch because of the bug report from openwrt. -- https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] About 802.11s mesh on IPQ4019, ath10k-ct and ct-firmware
Sven Eckelmann writes: > On Saturday, 16 March 2019 13:18:48 CET Xuebing Wang wrote: > [...] >> 1) Firmware inside QSDK (QCA closed source?) for AP-DK04.1-C1 based >> routers. >> 2) Firmware from kvalo/linux-firmware >> >> Are these "2 lines" of firmware essentially the same? > > They should at least be quite similar. Maybe Kalle knows more about > it. I don't know what firmware QSDK has and if it's tested with ath10k. My recommendation is to take ath10k firmware images from linux-firmware as they are tested with ath10k. -- Kalle Valo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] WDS and adhoc support with ath10k
Yeoh Chun-Yeow yeohchuny...@gmail.com writes: Could someone confirm if WDS and adhoc mode currently don't have support with this driver? adhoc is working but not perfect, such as rate control not working, no HT/VHT rate, and etc. You need to use the firmware version 999.999.0.636. WDS should be working since 4 addresses has fixed by Michal: http://lists.infradead.org/pipermail/ath10k/2014-February/001191.html But the version of ath10k in openwrt is starting to become old, I doubt it has Michal's fix. -- Kalle Valo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCHv3] wifi: Introduce 802.11ac support
(Adding ath...@lists.infradead.org) I think AP is by far the most common use case for OpenWrt, and DFS support for example is only for the AP-branch firmware (as I found out after some intense study of the ath10k/cfg80211/mac80211 source Oh, I didn't know that. But that's not suprising as almost all of AP mode testing happens with 10.1 firmware. -- maybe the firmware features should be better documented...) Sure, it's just lack of time on my part. Any help with documentation would be appreciated. Does AP firmware support plain STA operation? Yes, but not that well tested. If it does, AP firmware should no doubt be the default in OpenWrt. I fully agree. This should be the first stage. If not, then we should maybe think of a way to support both. For the second stage I think we should try improve how to make it easier to switch between firmwares (see my previous email). -- Kalle Valo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCHv3] wifi: Introduce 802.11ac support
Sven Eckelmann s...@open-mesh.com writes: The ath10k patch wasn't resent because the driver patches are now integrated in the OpenWrt mac80211 package. The answer in http://article.gmane.org/gmane.comp.embedded.openwrt.devel/22422 also wasn't quite promising. What do you mean? What was wrong with my answer? -- Kalle Valo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/2] Initial 11ac support using ath10k
Sven Eckelmann s...@open-mesh.com writes: On Saturday 18 January 2014 01:14:28 Kalle Valo wrote: Just as general information to the state of ath10k, my current test showed some problems with it: * Samsung GT-I9300 only got horrible slow connections to an QCA9880 but an Intel N6205 (using iwlwifi from v3.12) or Samsung S4 worked fine Could you report the I9300 issue to the ath10k list with more details, please? We can try to investigate it. This is a little bit problematic. I could reproduce this problem quite well on a specific date and when I tried some other day it worked fine. So it is hard to report anything. The only thing I could report would be the Failed to add peer problem which seemed to happen at the same time. Maybe I find a way to reproduce it reliable but I don't know how at the moment. The bug report doesn't need to be perfect, not all bugs are easily reproducable, but just knowing about a bug would even help. That's why ask people to send bug reports to ath...@lists.infradead.org. * Adhoc mode doesn't work at all That was with 10.1 firmware? AFAIK it doesn't support adhoc at all. I think we need to add a firmware feature flag to disable adhoc with that firmware. It used the latest and greatest, stable(?) version of the firmware when the patchset was generated: ap/firmware-2.bin_10.1.467-1 The statement doesn't support adhoc at all makes me a little bit nervous. Would you say that it is better to completely ignore the ap directory of the firmware repo [2]? Which benefits does the ap firmware has over the ath10k firmware? So we have two firmware branches right now, main and 10.1. 10.1 is solely focused on AP mode, nothing else. The main branch again has more features, like P2P, but doesn't support AP mode as well as 10.1 does. -- Kalle Valo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/2] Initial 11ac support using ath10k
(resending my mail due to a stupid rule in ath10k-devel, I need to be subcribed before posting to that list) Hi Sven, adding ath...@lists.infradead.org. Sven Eckelmann s...@open-mesh.com writes: Hi, support for ath10k cards was added a while ago to OpenWrt. Unfortunately, the actual 802.11ac support was never added (patches on the mailing lists were just ignored). This is a rather unpleasant situation when trying to get some 11ac test hardware working. Yeah, it would be great to get proper ath10k support to OpenWrt. Thanks for working on this! I've picked up the patches and rebased them on top of the current master branch/trunk. Where did you take the ath10k patches? ath10k is under heavy development, so I strongly recommend taking patches directly from ath-next branch of my ath.git. That way you would be using the latest and greatest. Just as general information to the state of ath10k, my current test showed some problems with it: * Samsung GT-I9300 only got horrible slow connections to an QCA9880 but an Intel N6205 (using iwlwifi from v3.12) or Samsung S4 worked fine Could you report the I9300 issue to the ath10k list with more details, please? We can try to investigate it. * Adhoc mode doesn't work at all That was with 10.1 firmware? AFAIK it doesn't support adhoc at all. I think we need to add a firmware feature flag to disable adhoc with that firmware. * TX bitrate information is bogus (iw XXX station dump) Yeah, this is annoying. But firmware doesn't report this to the host at all so there is not much ath10k can do right now. But I'll send a query to the firmware team if they could provide that information to ath10k. * Crashed relative often on reconfiguration: Data bus error, epc 87b7a864, ra 87b7a864 On some QCA988x boards cold reset seems to cause problems on the PCI bus. We are investigating this. * Sometimes adding of station seems to fail: ath10k: Failed to add peer 5c:0a:5b:4e:6a:c4 for vdev 1 when adding a new sta: -145 This is new to me. Can you report this to the ath10k list, please? * Adhoc interface + iw dev wlan0 scan trigger just crashes the firmware: [ 296.16] ath10k: firmware crashed! [ 296.17] ath10k: hardware name qca988x hw2.0 version 0x4100016c [ 296.17] ath10k: firmware version: 65.467.0.0 What firmware version was this? The version printed here seems to be corrupted. -- Kalle Valo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
