linux-kernel - Re: [cfg80211 / iwlwifi] setting wireless regulatory domain doesn't work.

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:	Wed, 18 Dec 2013 10:26:25 +0100
From:	Johannes Berg <johannes@...solutions.net>
To:	Arend van Spriel <arend@...adcom.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Sander Eikelenboom <linux@...elenboom.it>,
	Ben Hutchings <ben@...adent.org.uk>,
	Julian Calaby <julian.calaby@...il.com>,
	"Luis R. Rodriguez" <mcgrof@...not-panic.com>,
	"Grumbach, Emmanuel" <emmanuel.grumbach@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"ilw@...ux.intel.com" <ilw@...ux.intel.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
	"John W. Linville" <linville@...driver.com>,
	Avinash Patil <avinashapatil@...il.com>
Subject: Re: [cfg80211 / iwlwifi] setting wireless regulatory domain doesn't
 work.

Hi all,

We really should be asking Luis to look at this who hasn't yet chimed
in, presumably because he's between jobs (and travelling IIRC)

On Wed, 2013-12-18 at 10:16 +0100, Arend van Spriel wrote:
> On 12/17/2013 11:06 PM, Linus Torvalds wrote:
> > We have literally had this *exact* same issue with firmware loading.
> > Network drivers shouldn't try to load firmware at module load time.
> > Same deal.
> 
> It is kind of a chicken and egg problem for (wireless) networking
> drivers. To get IFF_UP from the network layer you have to register a
> netdevice. For wireless drivers this means you have to register a wiphy
> device with cfg80211 which flags capabilities and optionally are custom
> regulatory domain. That information depends on the device and firmware
> used. And there we have a full circle.

This is all really beside the point.

For this CRDA information, the kernel never actually *waits* for it, so
in the case that there's no reply, it uses the built-in world domain. So
it's not like request_firmware(), which will block boot forever, but
it's also not like request_firmware_nowait() which will eventually time
out and come back with an error if userspace isn't handling it (though
now that firmware loading is built in ...)

The issue is that it uses the built-in data *forever*, and what Sander
said was "or it will block forever" but just meant that it never was
able to do any further updates.

It *doesn't* actually block the boot process or such. Everything Linus
said is true but seems to have been written in understanding "blocks" as
"blocking the boot process", rather than "blocking further updates".

Regardless of this, even blocking further updates is a really bad idea.
There are a few ways to handle this, but I'll let Luis poke at that.

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/