linux-kernel - Re: [PATCH v9 0/2] wifi: mwifiex: add code to support host mlme

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 15 Mar 2024 17:07:43 -0700
From: Brian Norris <briannorris@...omium.org>
To: David Lin <yu-hao.lin@....com>
Cc: linux-wireless@...r.kernel.org, linux-kernel@...r.kernel.org,
	kvalo@...nel.org, francesco@...cini.it, tsung-hsien.hsieh@....com,
	rafael.beims@...adex.com,
	Francesco Dolcini <francesco.dolcini@...adex.com>
Subject: Re: [PATCH v9 0/2] wifi: mwifiex: add code to support host mlme

On Wed, Mar 06, 2024 at 10:00:51AM +0800, David Lin wrote:
> With host mlme:
> Tested-by: <rafael.beims@...adex.com> #Verdin AM62 IW416 SD
> Without host mlme:
> Tested-by: Francesco Dolcini <francesco.dolcini@...adex.com> # 88W8997-SD
> 
> This series add host based MLME support to the mwifiex driver, this
> enables WPA3 support in both client and AP mode.
> To enable WPA3, a firmware with corresponding V2 Key API support is
> required.
> The feature is currently only enabled on NXP IW416 (SD8978), and it
> was internally validated by NXP QA team. Other NXP Wi-Fi chips
> supported in current mwifiex are not affected by this change.

Thank you for all the evoluation in this series. This looks much better
than it did at the start, and I appreciate the additional explanation of
featureset (HW and FW versions). I'm not sure if this has been
asked/answered before, but are the MLME/WPA3 limitations exclusively
tied to the firmware support ("V2 Key API")? Or are there hardware
limitations on top (e.g., some firmware might get "V2 Key API" but still
be unsupported on a given chip family)? Could other chips chips
theoretically get this feature-set in the future?

In absence of a clear answer on this, it's definitely a good idea to do
things like you have in this series now -- that you have a short-list
(of 1) of HW where where it's validated, and additionally a FW
feature/revision check to ensure it's running appropriate firmware. But
I just wonder what the feasibility would be for adding to the shortlist
(or providing users/developers the option of doing so) in the future, if
people are so inclined.

To be clear, this is mostly an informational curiosity and
forward-looking question -- not a request to change the implementation
in this series.

Thanks,
Brian