linux-kernel - Re: [PATCH] wifi: brcmfmac: cfg80211: Use WSEC to set SAE password

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: Tue, 19 Dec 2023 20:01:39 +0900
From: Hector Martin <marcan@...can.st>
To: Arend Van Spriel <arend.vanspriel@...adcom.com>,
 Kalle Valo <kvalo@...nel.org>
Cc: Arend van Spriel <aspriel@...il.com>, Franky Lin
 <franky.lin@...adcom.com>, Hante Meuleman <hante.meuleman@...adcom.com>,
 Daniel Berlin <dberlin@...rlin.org>, linux-wireless@...r.kernel.org,
 brcm80211-dev-list.pdl@...adcom.com, SHA-cyfmac-dev-list@...ineon.com,
 linux-kernel@...r.kernel.org, asahi@...ts.linux.dev
Subject: Re: [PATCH] wifi: brcmfmac: cfg80211: Use WSEC to set SAE password



On 2023/12/19 17:52, Arend Van Spriel wrote:
> On December 17, 2023 12:25:23 PM Kalle Valo <kvalo@...nel.org> wrote:
> 
>> Hector Martin <marcan@...can.st> wrote:
>>
>>> Using the WSEC command instead of sae_password seems to be the supported
>>> mechanism on newer firmware, and also how the brcmdhd driver does it.
>>>
>>> According to user reports [1], the sae_password codepath doesn't actually
>>> work on machines with Cypress chips anyway, so no harm in removing it.
>>>
>>> This makes WPA3 work with iwd, or with wpa_supplicant pending a support
>>> patchset [2].
>>>
>>> [1] https://rachelbythebay.com/w/2023/11/06/wpa3/
>>> [2] http://lists.infradead.org/pipermail/hostap/2023-July/041653.html
>>>
>>> Signed-off-by: Hector Martin <marcan@...can.st>
>>> Reviewed-by: Neal Gompa <neal@...pa.dev>
>>
>> Arend, what do you think?
>>
>> We recently talked about people testing brcmfmac patches, has anyone else
>> tested this?
> 
> Not sure I already replied so maybe I am repeating myself. I would prefer 
> to keep the Cypress sae_password path as well although it reportedly does 
> not work. The vendor support in the driver can be used to accommodate for 
> that. The other option would be to have people with Cypress chipset test 
> this patch. If that works for both we can consider dropping the 
> sae_password path.
> 
> Regards,
> Arend

So, if nobody from Cypress chimes in ever, and nobody cares nor tests
Cypress chipsets, are we keeping any and all existing Cypress code-paths
as bitrotting code forever and adding gratuitous conditionals every time
any functionality needs to change "just in case it breaks Cypress" even
though it has been tested compatible on Broadcom chipsets/firmware?

Because that's not sustainable long term.

- Hector