netdev - Re: [PATCH 1/1] wifi: nl80211: Add support for plumbing SAE groups to driver

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] [day] [month] [year] [list]

Date: Tue, 27 Feb 2024 20:27:41 +0100
From: Johannes Berg <johannes@...solutions.net>
To: Jeff Johnson <quic_jjohnson@...cinc.com>, Jakub Kicinski
 <kuba@...nel.org>
Cc: Kalle Valo <kvalo@...nel.org>, Vinayak Yadawad
	 <vinayak.yadawad@...adcom.com>, linux-wireless@...r.kernel.org, 
	jithu.jance@...adcom.com, Arend van Spriel <arend.vanspriel@...adcom.com>, 
	netdev@...r.kernel.org
Subject: Re: [PATCH 1/1] wifi: nl80211: Add support for plumbing SAE groups
 to driver

Hi,

Sorry, I buried this thread because I thought I needed more time to
respond than I had two weeks ago, and then forgot about it. My bad.

On Wed, 2024-02-14 at 08:57 -0800, Jeff Johnson wrote:
> There are good reasons these out-of-tree drivers exist, but there is
> also a movement, at least for the Qualcomm infrastructure products, to
> transition to an upstream driver, in part due to customer requests. So
> it is disconcerting that you are talking about inserting barriers to
> converting to an upstream driver.

FWIW, I don't think of what I wrote as advocating for *inserting*
barriers that didn't already exist today.

> But we need our userspace interfaces to survive since both
> Qualcomm and our customers have years of work invested in the existing
> userspace interfaces and applications. The customers who want an
> upstream driver do not want to be forced to rewrite their applications
> to support it.

Then maybe they don't _really_ want an upstream driver? What's their
reasoning for wanting an upstream driver anyway - usually it ends up
being something around upstream's checks & balances, etc. But not
inventing gratuitous API differences is part of those?

> In the kernel we have a clear mantra to not break userspace. That should
> hopefully hold true when converting from an out-of-tree driver to an
> upstream one.

No, not at all? The kernel's policy of not breaking userspace
unsurprisingly only extends to ... the kernel. Whatever happened out of
tree isn't covered, and really shouldn't be. It doesn't even really
quite extend to staging. And this policy is actually often a reason
_not_ to include something in the kernel, until userspace interfaces
stabilize.

And since this was prompted by my mention of vendor APIs: Our upstream
stance on vendor APIs has been debated and consequently documented here:
https://wireless.wiki.kernel.org/en/developers/documentation/nl80211#vendor-specific_api

As far as I'm concerned, there's no intention of deviating from that
policy for the purpose of getting a currently non-upstream driver into
the tree.

johannes