linux-kernel - Re: [PATCH] Revert "ipw2200: select CFG80211

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]

Message-ID: <1420484224.9459.16.camel@sipsolutions.net>
Date:	Mon, 05 Jan 2015 19:57:04 +0100
From:	Johannes Berg <johannes@...solutions.net>
To:	Paul Bolle <pebolle@...cali.nl>
Cc:	Arend van Spriel <arend@...adcom.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Marcel Holtmann <marcel@...tmann.org>,
	Stanislav Yakovlev <stas.yakovlev@...il.com>,
	Kalle Valo <kvalo@...eaurora.org>,
	Jiri Kosina <jkosina@...e.cz>,
	linux-wireless <linux-wireless@...r.kernel.org>,
	Network Development <netdev@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Revert "ipw2200: select CFG80211_WEXT"

On Mon, 2015-01-05 at 18:38 +0100, Paul Bolle wrote:

> > ipw2200 is a WEXT driver using some wext functionality (and struct 
> > wiphy) provided by cfg80211 hence it needs CFG80211_WEXT. I guess that 
> > is what makes it confusing.
> 
> It doesn't help that I hardly know anything about mac80211, cfg80211 and
> nl80211 (and lib80211 for that matter). To me these are mostly just
> names that end in 80211.

:-)
There isn't really all that much that ipw2x00 is using from cfg80211
though - of note is that it has completely empty ops:

static struct cfg80211_ops libipw_config_ops = { };

IOW - all it does is register with the framework - courtesy of
a3caa99e6c68f. It's practically useless.

> Anyhow, concerning, CFG80211_WEXT: it seems the only functionality
> provided by that symbol that ipw2200 uses directly is
> cfg80211_wext_giwname(). Perhaps ipw2200 could have a private version of
> that function, something like ipw2100's ipw2100_wx_get_name(). Should be
> trivial to implement (ie, it could take _me_ a day or two).

We could just revert that part of the commit above - or even completely.

However, in theory at least doing *that* would now be a userspace
regression - today you can at least discover the presence of ipw2200
devices with nl80211, even if you can't do anything with them that way.

> But perhaps ipw2200 uses CFG80211_WEXT _indirectly_ too. Ie, in
> net/wireless/core.c I stumbled on
>     #ifdef CONFIG_CFG80211_WEXT
>             rdev->wiphy.wext = &cfg80211_wext_handler;
>     #endif

I don't think it does - see the note about the ops above. If it did,
it'd have to implement the ops.

> But I net/wireless/wext-core.c I then found
>     #ifdef CONFIG_CFG80211_WEXT
>             if (dev->ieee80211_ptr && dev->ieee80211_ptr->wiphy)
>                     handlers = dev->ieee80211_ptr->wiphy->wext;
>     #endif
>     #ifdef CONFIG_WIRELESS_EXT
>             if (dev->wireless_handlers)
>                     handlers = dev->wireless_handlers;
>     #endif
> 
> (There's much more to discover about WEXT, of course.) Anyhow, IPW2200
> uses both CFG80211_WEXT and WIRELESS_EXT and cfg80211_wext_handler and
> ipw2200's wireless_handlers appear to cover the same set of IOCTLS (one
> exception: SIOCSIWPMKSA). So by now I'm really puzzled how this all fits
> together.

Well, this was meant as a transition mechanism for drivers. Ultimately,
the way we thought how you'd convert a driver (and how we converted
mac80211) would be to have the wext handlers like for example the scan
ones:

static iw_handler ipw_wx_handlers[] = {
...
        IW_HANDLER(SIOCSIWSCAN, ipw_wx_set_scan),
        IW_HANDLER(SIOCGIWSCAN, ipw_wx_get_scan),
...
};

Then you could make a patch that uses the cfg80211 APIs for scanning in
the driver -- i.e. implement the cfg80211_ops.scan method, report frames
to the cfg80211 scanning and remove all the ieee->network_list stuff
etc. using the related cfg80211 API (e.g. cfg80211_get_bss() and friends
for getting a network, etc.) And then you'd change the handlers to be

static iw_handler ipw_wx_handlers[] = {
...
        IW_HANDLER(SIOCSIWSCAN, cfg80211_wext_siwscan),
        IW_HANDLER(SIOCGIWSCAN, cfg80211_wext_giwscan),
...
};

This part would have to be done in a single patch.

Multiple other groups of ioctls could be converted in similar patches,
until at the end you can completely remove ipw_wx_handlers and rely
entirely on cfg80211's wext compatibility.

So far the theory - in practice nobody cared enough to start working on
any of these drivers, let alone actually has the hardware today.

johannes

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/