linux.git/net/wireless/reg.c, branch v4.15

cfg80211: fully initialize old channel for event

2018-01-15T08:15:03+00:00

Paul reported that he got a report about undefined behaviour
that seems to me to originate in using uninitialized memory
when the channel structure here is used in the event code in
nl80211 later.

He never reported whether this fixed it, and I wasn't able
to trigger this so far, but we should do the right thing and
fully initialize the on-stack structure anyway.

Reported-by: Paul Menzel 
Signed-off-by: Johannes Berg

cfg80211: initialize regulatory keys/database later

2017-11-20T15:55:29+00:00

When cfg80211 is built as a module, everything is fine, and we
can keep the code as is; in fact, we have to, because there can
only be a single module_init().

When cfg80211 is built-in, however, it needs to initialize
before drivers (device_initcall/module_init), and thus used to
be at subsys_initcall(). I'd moved it to fs_initcall() earlier,
where it can remain. However, this is still too early because at
that point the key infrastructure hasn't been initialized yet,
so X.509 certificates can't be parsed yet.

To work around this problem, load the regdb keys only later in
a late_initcall(), at which point the necessary infrastructure
has been initialized.

Fixes: 90a53e4432b1 ("cfg80211: implement regdb signature checking")
Reported-by: Xiaolong Ye 
Signed-off-by: Johannes Berg

cfg80211: fix CFG80211_EXTRA_REGDB_KEYDIR typo

2017-10-13T12:08:42+00:00

The missing CONFIG_ prefix means this macro is never defined,
leading to a possible Kbuild warning:

net/wireless/reg.c:666:20: error: 'load_keys_from_buffer' defined but not used [-Werror=unused-function]
 static void __init load_keys_from_buffer(const u8 *p, unsigned int buflen)

When we use the correct symbol, the warning also goes away.

Fixes: 90a53e4432b1 ("cfg80211: implement regdb signature checking")
Signed-off-by: Arnd Bergmann 
Signed-off-by: Johannes Berg

cfg80211: implement regdb signature checking

2017-10-11T12:24:24+00:00

Currently CRDA implements the signature checking, and the previous
commits added the ability to load the whole regulatory database
into the kernel.

However, we really can't lose the signature checking, so implement
it in the kernel by loading a detached signature (regulatory.db.p7s)
and check it against built-in keys.

Signed-off-by: Johannes Berg

cfg80211: reg: remove support for built-in regdb

2017-10-11T11:18:51+00:00

Parsing and building C structures from a regdb is no longer needed
since the "firmware" file (regulatory.db) can be linked into the
kernel image to achieve the same effect.

Signed-off-by: Johannes Berg

cfg80211: support reloading regulatory database

2017-10-11T11:04:15+00:00

If the regulatory database is loaded, and then updated, it may
be necessary to reload it. Add an nl80211 command to do this.

Note that this just reloads the database, it doesn't re-apply
the rules from it immediately.

Signed-off-by: Johannes Berg

cfg80211: support loading regulatory database as firmware file

2017-10-11T11:04:15+00:00

As the current regulatory database is only about 4k big, and already
difficult to extend, we decided that overall it would be better to
get rid of the complications with CRDA and load the database into the
kernel directly, but in a new format that is extensible.

The new file format can be extended since it carries a length field
on all the structs that need to be extensible.

In order to be able to request firmware when the module initializes,
move cfg80211 from subsys_initcall() to the later fs_initcall(); the
firmware loader is at the same level but linked earlier, so it can
be called from there. Otherwise, when both the firmware loader and
cfg80211 are built-in, the request will crash the kernel. We also
need to be before device_initcall() so that cfg80211 is available
for devices when they initialize.

Signed-off-by: Johannes Berg

cfg80211: honor NL80211_RRF_NO_HT40{MINUS,PLUS}

2017-09-06T10:56:31+00:00

Honor the NL80211_RRF_NO_HT40{MINUS,PLUS} flags in
reg_process_ht_flags_channel. Not doing so leads can lead
to a firmware assert in iwlwifi for example.

Fixes: b0d7aa59592b ("cfg80211: allow wiphy specific regdomain management")
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Johannes Berg

cfg80211: Fix dfs state propagation for non-DFS center channel

2017-04-25T19:42:52+00:00

When part of a bigger bandwidth (160 MHz) channel falls in DFS
channel range it is possible that the  center frequency may not
necessarily be a radar channel. Remove the sanity check on channel
flag for IEEE80211_CHAN_RADAR in regulatory_propagate_dfs_state(),
this should fix the dfs state propagation for non-DFS center freq
which has DFS channels in it's bandwidth, should also fix unnecessary
WARN_ON() spam in regulatory_propagate_dfs_state().

Fixes: 8976672736d6 ("cfg80211: Share Channel DFS state across wiphys of same DFS domain")
Reported-by: Johannes Berg 
Signed-off-by: Vasanthakumar Thiagarajan 
Signed-off-by: Johannes Berg

cfg80211: Share Channel DFS state across wiphys of same DFS domain

2017-03-06T12:54:20+00:00

Sharing DFS channel state across multiple wiphys (radios) could
be useful with multiple radios on the system. When one radio
completes CAC and markes the channel available another radio
can use this information and start beaconing without really doing
CAC.

Whenever there is a state change in dfs channel associated to
a particular wiphy the the same state change is propagated to
other wiphys having the same DFS reg domain configuration.
Also when a new wiphy is created the dfs channel state of
other existing wiphys of same DFS domain is copied.

Signed-off-by: Vasanthakumar Thiagarajan 
Signed-off-by: Johannes Berg