mbox series

[0/2] wifi: nl80211/wilc1000: force WLAN_AKM_SUITE_SAE to big endian in NL80211_CMD_EXTERNAL_AUTH

Message ID 20240215-nl80211_fix_akm_suites_endianness-v1-0-57e902632f9d@bootlin.com (mailing list archive)
Headers show
Series wifi: nl80211/wilc1000: force WLAN_AKM_SUITE_SAE to big endian in NL80211_CMD_EXTERNAL_AUTH | expand

Message

Alexis Lothoré (eBPF Foundation) Feb. 15, 2024, 2:13 p.m. UTC
This small series is the follow-up to discussions started around a sparse
warning in wilc1000 driver ([1]) and implements the solution suggested by
Johannes. It moves a historically needed conversion to be32 in nl80211 (in
NL80211_CMD_EXTERNAL_AUTH, specifically on NL80211_ATTR_AKM_SUITES property
_only_ when it is set to WLAN_AKM_SUITE_SAE) The user scenario affected by
this update is a connect process on a WPA3-protected access point with
authentication offloaded to user-space. Two drivers are affected by the
update: wilc1000 and qtnfmac. wilc1000 case is handled by a small
companion patch which also fixes the sparse warning.

For the quantenna driver, I don't really get how it manipulates AKM suites.
The only thing it currently does on it before calling nl80211 is a
le32_to_cpu. IIUC the raw value (before applying le32_to_cpu) comes from
chip/firmware:
<interrupt>
 qtnf_shm_ipc_irq_handler
  <some callbacks chains>
   qtnf_pcie_control_rx_callback
    qtnf_trans_handle_rx_ctl_packet
     qtnf_trans_event_enqueue => queue skb to processing queue

qtnf_event_work_handler <= dequeue corresponding skb to process
 qtnf_event_process_skb
  qtnf_event_parse
   qtnf_event_handle_external_auth
    cfg80211_external_auth_request => sends NL80211_CMD_EXTERNAL_AUTH

There is no cast to big endian on AKM suite at any point in this chain, but
there are plenty of leXX_to_cpu, so I assume the chip/its firmware sends
its data in little endian. Then, since the be32 conversion is _needed_ with
current wpa_supplicant, I wonder if it works at all in current state, so I
did not modify it. Or has it been tested with another supplicant (iwd ?)
which handles WLAN_AKM_SUITE_SAE differently ? Opinions (and even some
testing) are welcome for this driver, since I do not have the corresponding
hardware.

[1] https://lore.kernel.org/linux-wireless/87a5uatfl1.fsf@kernel.org/

To: Johannes Berg <johannes@sipsolutions.net>
Cc: Ajay Singh <ajay.kathat@microchip.com>
Cc: Kalle Valo <kvalo@kernel.org>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: <linux-wireless@vger.kernel.org>
Cc: <linux-kernel@vger.kernel.org>
Cc: Igor Mitsyanko <imitsyanko@quantenna.com>
Cc: Sergey Matyukevich <geomatsi@gmail.com>

Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
---
Alexis Lothoré (2):
      wifi: nl80211: force WLAN_AKM_SUITE_SAE in big endian in NL80211_CMD_EXTERNAL_AUTH
      wifi: wilc1000: remove AKM suite be32 conversion for external auth request

 drivers/net/wireless/microchip/wilc1000/cfg80211.c |  2 +-
 net/wireless/nl80211.c                             | 19 ++++++++++++++++++-
 2 files changed, 19 insertions(+), 2 deletions(-)
---
base-commit: a4c7842e88b0f7d937015e4588ea2a1dec33cf2c
change-id: 20240214-nl80211_fix_akm_suites_endianness-2750a5d7da83

Best regards,

Comments

Alexis Lothoré (eBPF Foundation) Feb. 15, 2024, 3:50 p.m. UTC | #1
On 2/15/24 15:13, Alexis Lothoré wrote:
> This small series is the follow-up to discussions started around a sparse
> warning in wilc1000 driver ([1]) and implements the solution suggested by
> Johannes. It moves a historically needed conversion to be32 in nl80211 (in
> NL80211_CMD_EXTERNAL_AUTH, specifically on NL80211_ATTR_AKM_SUITES property
> _only_ when it is set to WLAN_AKM_SUITE_SAE) The user scenario affected by
> this update is a connect process on a WPA3-protected access point with
> authentication offloaded to user-space. Two drivers are affected by the
> update: wilc1000 and qtnfmac. wilc1000 case is handled by a small
> companion patch which also fixes the sparse warning.

Adding Claudio Beznea (co-maintainer for WILC), who got lost when I prepared the
series, sorry.

Also, my mail provider returns error 550 (No Such User Here) for quantenna
driver maintainer (<imitsyanko@quantenna.com>, taken from MAINTAINERS). I've
seen no recent activity from him on the ML, is he still around ?
Kalle Valo Feb. 15, 2024, 5:06 p.m. UTC | #2
(changing subject)

Alexis Lothoré <alexis.lothore@bootlin.com> writes:

> Also, my mail provider returns error 550 (No Such User Here) for quantenna
> driver maintainer (<imitsyanko@quantenna.com>, taken from MAINTAINERS). I've
> seen no recent activity from him on the ML, is he still around ?

I found a bounce for imitsyanko@quantenna.com from 2022 so I guess it's
time to orphan qtnfmac?

Also the purelife maintainer Srini Raju (CCed) is bouncing, that's
another candidate to orphan.

PURELIFI PLFXLC DRIVER
M:      Srinivasan Raju <srini.raju@purelifi.com>
L:      linux-wireless@vger.kernel.org
S:      Supported
F:      drivers/net/wireless/purelifi/plfxlc/
Kalle Valo Feb. 15, 2024, 5:21 p.m. UTC | #3
Kalle Valo <kvalo@kernel.org> writes:

> (changing subject)
>
> Alexis Lothoré <alexis.lothore@bootlin.com> writes:
>
>> Also, my mail provider returns error 550 (No Such User Here) for quantenna
>> driver maintainer (<imitsyanko@quantenna.com>, taken from MAINTAINERS). I've
>> seen no recent activity from him on the ML, is he still around ?
>
> I found a bounce for imitsyanko@quantenna.com from 2022 so I guess it's
> time to orphan qtnfmac?
>
> Also the purelife maintainer Srini Raju (CCed) is bouncing, that's
> another candidate to orphan.

And confirmed, I just got bounces for both of these maintainers. Patches
welcome to orphan these drivers.

<srini.raju@purelifi.com>: host
    purelifi-com.mail.protection.outlook.com[52.101.68.16] said: 550 5.4.1
    Recipient address rejected: Access denied.
    [DB5PEPF00014B8D.eurprd02.prod.outlook.com 2024-02-15T17:07:03.735Z
    08DC2C530F4F7910] (in reply to RCPT TO command)

<imitsyanko@quantenna.com>: host mail.quantenna.com[50.87.249.29] said: 550 No
    Such User Here (in reply to RCPT TO command)
Jeff Johnson Feb. 15, 2024, 6:51 p.m. UTC | #4
On 2/15/2024 9:21 AM, Kalle Valo wrote:
> <imitsyanko@quantenna.com>: host mail.quantenna.com[50.87.249.29] said: 550 No
>     Such User Here (in reply to RCPT TO command)

Apparently Quantenna was acquired by ON Semi in 2019[1], and in 2022
they closed it down[2]. Seems pretty abandoned to me.

[1]
https://www.eetimes.com/on-semi-to-acquire-wi-fi-chip-vendor-quantenna-for-1-billion/
[2]
https://www.bizjournals.com/phoenix/news/2022/09/20/onsemi-close-down-quantenna.html
Kalle Valo Feb. 16, 2024, 9:37 a.m. UTC | #5
Jeff Johnson <quic_jjohnson@quicinc.com> writes:

> On 2/15/2024 9:21 AM, Kalle Valo wrote:
>> <imitsyanko@quantenna.com>: host mail.quantenna.com[50.87.249.29] said: 550 No
>>     Such User Here (in reply to RCPT TO command)
>
> Apparently Quantenna was acquired by ON Semi in 2019[1], and in 2022
> they closed it down[2]. Seems pretty abandoned to me.

Thanks Jeff. I do wonder is anyone even using qtnfmac and plfxlc? Maybe
we should just delete the drivers as nobody seems to care about them?
Igor Mitsyanko Feb. 26, 2024, 2:13 a.m. UTC | #6
On 2/16/24 01:37, Kalle Valo wrote:
> Jeff Johnson <quic_jjohnson@quicinc.com> writes:
>
>> On 2/15/2024 9:21 AM, Kalle Valo wrote:
>>> <imitsyanko@quantenna.com>: host mail.quantenna.com[50.87.249.29] said: 550 No
>>>      Such User Here (in reply to RCPT TO command)
>> Apparently Quantenna was acquired by ON Semi in 2019[1], and in 2022
>> they closed it down[2]. Seems pretty abandoned to me.
> Thanks Jeff. I do wonder is anyone even using qtnfmac and plfxlc? Maybe
> we should just delete the drivers as nobody seems to care about them?
>
(replacing imitsyanko@quantenna.com with my personal email)

Hi Kalle, Jeff,

that's right, Quantenna division was shutdown by ON. To my knowledge no 
users of qtnfmac drivers are left after that. I would think removing 
driver altogether is the right approach. I'm not associated with ON 
anymore so it's just my personal opinion.

CCing Krystal Heaton who I found on ON "contacts" web page (just in case 
someone from ON wants to comment if removing qtnfmac driver from Linux 
kernel is a concern).
Kalle Valo Feb. 27, 2024, 2 p.m. UTC | #7
Igor Mitsyanko <i.mitsyanko@gmail.com> writes:

> On 2/16/24 01:37, Kalle Valo wrote:
>> Jeff Johnson <quic_jjohnson@quicinc.com> writes:
>>
>>> On 2/15/2024 9:21 AM, Kalle Valo wrote:
>>>> <imitsyanko@quantenna.com>: host mail.quantenna.com[50.87.249.29] said: 550 No
>>>>      Such User Here (in reply to RCPT TO command)
>>> Apparently Quantenna was acquired by ON Semi in 2019[1], and in 2022
>>> they closed it down[2]. Seems pretty abandoned to me.
>> Thanks Jeff. I do wonder is anyone even using qtnfmac and plfxlc? Maybe
>> we should just delete the drivers as nobody seems to care about them?
>>
> (replacing imitsyanko@quantenna.com with my personal email)
>
> Hi Kalle, Jeff,
>
> that's right, Quantenna division was shutdown by ON. To my knowledge
> no users of qtnfmac drivers are left after that. I would think
> removing driver altogether is the right approach. I'm not associated
> with ON anymore so it's just my personal opinion.
>
> CCing Krystal Heaton who I found on ON "contacts" web page (just in
> case someone from ON wants to comment if removing qtnfmac driver from
> Linux kernel is a concern).

Sad news but thanks for letting us know. So unless anyone else objects
the plan is to remove qtnfmac driver in the near future.
Stefan Lippers-Hollmann Feb. 28, 2024, 3:02 a.m. UTC | #8
Hi

On 2024-02-27, Kalle Valo wrote:
> Igor Mitsyanko <i.mitsyanko@gmail.com> writes:
> > On 2/16/24 01:37, Kalle Valo wrote:
> >> Jeff Johnson <quic_jjohnson@quicinc.com> writes:
> >>> On 2/15/2024 9:21 AM, Kalle Valo wrote:
[...]
> > that's right, Quantenna division was shutdown by ON. To my knowledge
> > no users of qtnfmac drivers are left after that. I would think
> > removing driver altogether is the right approach. I'm not associated
> > with ON anymore so it's just my personal opinion.
> >
> > CCing Krystal Heaton who I found on ON "contacts" web page (just in
> > case someone from ON wants to comment if removing qtnfmac driver from
> > Linux kernel is a concern).
>
> Sad news but thanks for letting us know. So unless anyone else objects
> the plan is to remove qtnfmac driver in the near future.

In theory, there would be quite a few /potential/ users for qtnfmac
and QT3840BC 'Topaz' (QSR1000) on a variety of early 802.11ac routers
and APs (particularly on ipq8064 SOCs[0]), but as the required qtnfmac
firmware for these chipsets has never been published, there is
no wireless support for (the typically 5 GHz-) "Topaz" wlan chipset
on those devices at all.

The devices are out there (albeit not the most common- or long-lived
combination), but they never had wireless support in the first place
(first because qtnfmac didn't support QSR1000, after that was
rectified[1], because the required firmware for qtnfmac/ QSR1000 has
never been published). It's a bit sad that these never got supported.

Regards
	Stefan Lippers-Hollmann

--
[0] e.g. Linksys E8350, Linksys E8400, Netgear R7500,
    ZyXEL NBG6816 (Armor Z1), ZyXEL WAP6806 (Armor X1) (on mt7621)
    [Disclaimer: I don't own any of these myself, but I regularly
    see requests for Topaz wireless support on the r7500 and e8350]
[1] Tue Oct 16 10:23:58 2018 +0000, qtnfmac: add support for Topaz
    chipsets
    e401fa25cfa23df8b17960a656ff11f49facae84