Received-SPF: pass (google.com: domain of linux-wireless+bounces-3800-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Message-ID: <a180980bd880a7d89e71ef0d0bb10c232cdf867f.camel@sipsolutions.net>
Subject: Re: [PATCH 3/8] wifi: mac80211:  make associated BSS pointer
 visible to the driver
From: Johannes Berg <johannes@sipsolutions.net>
To: linux-wireless@vger.kernel.org
Date: Tue, 20 Feb 2024 09:29:14 +0100
In-Reply-To: <25c51905aac00bde0591d169d00b301c608234c5.camel@sipsolutions.net>
References: <20240206145411.3217588-1-miriam.rachel.korenblit@intel.com>
	 <20240206164849.6fe9782b87b4.Ifbffef638f07ca7f5c2b27f40d2cf2942d21de0b@changeid>
	 <25c51905aac00bde0591d169d00b301c608234c5.camel@sipsolutions.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.50.3 (3.50.3-1.fc39) 
Precedence: bulk
MIME-Version: 1.0

On Mon, 2024-02-12 at 14:45 +0100, Johannes Berg wrote:
> On Tue, 2024-02-06 at 16:54 +0200, Miri Korenblit wrote:
> > Some drivers need the data in it, so move it to the link conf,
> > which is exposed to the driver.
>=20
> > + * @bss: the cfg80211 bss descriptor. Valid only for a station, and on=
ly
> > + *	when associated.
> >=20
>=20
> For the record, I'm dropping this patch.
>=20
> Yes, the data is there in the stack, but the cfg80211 BSS contains data
> that is not authenticated (from probe responses etc.) whereas mac80211
> is (hopefully always) operating on data that is authenticated with
> beacon protection.
>=20
> So exposing this to the driver feels fragile - if it actually gets used
> for pretty much anything, it won't necessarily be authenticated data.

Changed my mind again ;-)

The issue ends up being as described above, but there are some other
things that the iwlwifi driver would like to access that are most easily
obtained via this information, not just RSSI. The other thing on our
list now is the BSS load, and we had a patch [1] to parse it in mac80211
and then it's authenticated, but really we don't care much for security
purposes and would like to also have it from probe responses which are
never authenticated.

[1] https://lore.kernel.org/r/20240216135047.b771830d9b12.If5885d651cb01147=
11ee1f6c1cb8fe31a69bf0a7@changeid


So I'll apply this patch with a documentation change to warn the data
contained is not authenticated, and drop the patch [1] linked above
instead. This gives the driver more flexibility, at the expense of
perhaps a slightly greater risk of using it for something it shouldn't
be used for, but the alternatives would put more driver-specific logic
into mac80211, which we don't really want either.

johannes