2007-07-27 17:43:23 +04:00
|
|
|
/*
|
|
|
|
* Copyright 2002-2005, Instant802 Networks, Inc.
|
|
|
|
* Copyright 2005-2006, Devicescape Software, Inc.
|
|
|
|
* Copyright 2006-2007 Jiri Benc <jbenc@suse.cz>
|
2008-04-08 19:56:52 +04:00
|
|
|
* Copyright 2007-2008 Johannes Berg <johannes@sipsolutions.net>
|
2007-07-27 17:43:23 +04:00
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License version 2 as
|
|
|
|
* published by the Free Software Foundation.
|
|
|
|
*/
|
|
|
|
|
2007-08-29 01:01:55 +04:00
|
|
|
#include <linux/if_ether.h>
|
|
|
|
#include <linux/etherdevice.h>
|
|
|
|
#include <linux/list.h>
|
[MAC80211]: fix race conditions with keys
During receive processing, we select the key long before using it and
because there's no locking it is possible that we kfree() the key
after having selected it but before using it for crypto operations.
Obviously, this is bad.
Secondly, during transmit processing, there are two possible races: We
have a similar race between select_key() and using it for encryption,
but we also have a race here between select_key() and hardware
encryption (both when a key is removed.)
This patch solves these issues by using RCU: when a key is to be freed,
we first remove the pointer from the appropriate places (sdata->keys,
sdata->default_key, sta->key) using rcu_assign_pointer() and then
synchronize_rcu(). Then, we can safely kfree() the key and remove it
from the hardware. There's a window here where the hardware may still
be using it for decryption, but we can't work around that without having
two hardware callbacks, one to disable the key for RX and one to disable
it for TX; but the worst thing that will happen is that we receive a
packet decrypted that we don't find a key for any more and then drop it.
When we add a key, we first need to upload it to the hardware and then,
using rcu_assign_pointer() again, link it into our structures.
In the code using keys (TX/RX paths) we use rcu_dereference() to get the
key and enclose the whole tx/rx section in a rcu_read_lock() ...
rcu_read_unlock() block. Because we've uploaded the key to hardware
before linking it into internal structures, we can guarantee that it is
valid once get to into tx().
One possible race condition remains, however: when we have hardware
acceleration enabled and the driver shuts down the queues, we end up
queueing the frame. If now somebody removes the key, the key will be
removed from hwaccel and then then driver will be asked to encrypt the
frame with a key index that has been removed. Hence, drivers will need
to be aware that the hw_key_index they are passed might not be under
all circumstances. Most drivers will, however, simply ignore that
condition and encrypt the frame with the selected key anyway, this
only results in a frame being encrypted with a wrong key or dropped
(rightfully) because the key was not valid. There isn't much we can
do about it unless we want to walk the pending frame queue every time
a key is removed and remove all frames that used it.
This race condition, however, will most likely be solved once we add
multiqueue support to mac80211 because then frames will be queued
further up the stack instead of after being processed.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Acked-by: Michael Wu <flamingice@sourmilk.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-09-14 19:10:24 +04:00
|
|
|
#include <linux/rcupdate.h>
|
2008-02-25 18:27:45 +03:00
|
|
|
#include <linux/rtnetlink.h>
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 11:04:11 +03:00
|
|
|
#include <linux/slab.h>
|
2011-07-15 19:47:34 +04:00
|
|
|
#include <linux/export.h>
|
2007-07-27 17:43:23 +04:00
|
|
|
#include <net/mac80211.h>
|
2012-02-20 14:38:41 +04:00
|
|
|
#include <asm/unaligned.h>
|
2007-07-27 17:43:23 +04:00
|
|
|
#include "ieee80211_i.h"
|
2009-04-23 20:52:52 +04:00
|
|
|
#include "driver-ops.h"
|
2007-07-27 17:43:23 +04:00
|
|
|
#include "debugfs_key.h"
|
|
|
|
#include "aes_ccm.h"
|
2009-01-08 14:32:02 +03:00
|
|
|
#include "aes_cmac.h"
|
2007-07-27 17:43:23 +04:00
|
|
|
|
2007-08-29 01:01:55 +04:00
|
|
|
|
2008-02-26 16:34:06 +03:00
|
|
|
/**
|
|
|
|
* DOC: Key handling basics
|
2007-08-29 01:01:55 +04:00
|
|
|
*
|
|
|
|
* Key handling in mac80211 is done based on per-interface (sub_if_data)
|
|
|
|
* keys and per-station keys. Since each station belongs to an interface,
|
|
|
|
* each station key also belongs to that interface.
|
|
|
|
*
|
2011-01-03 21:51:09 +03:00
|
|
|
* Hardware acceleration is done on a best-effort basis for algorithms
|
|
|
|
* that are implemented in software, for each key the hardware is asked
|
|
|
|
* to enable that key for offloading but if it cannot do that the key is
|
|
|
|
* simply kept for software encryption (unless it is for an algorithm
|
|
|
|
* that isn't implemented in software).
|
|
|
|
* There is currently no way of knowing whether a key is handled in SW
|
|
|
|
* or HW except by looking into debugfs.
|
2007-08-29 01:01:55 +04:00
|
|
|
*
|
2011-01-03 21:51:09 +03:00
|
|
|
* All key management is internally protected by a mutex. Within all
|
|
|
|
* other parts of mac80211, key references are, just as STA structure
|
|
|
|
* references, protected by RCU. Note, however, that some things are
|
|
|
|
* unprotected, namely the key->sta dereferences within the hardware
|
|
|
|
* acceleration functions. This means that sta_info_destroy() must
|
|
|
|
* remove the key which waits for an RCU grace period.
|
2007-08-29 01:01:55 +04:00
|
|
|
*/
|
|
|
|
|
|
|
|
static const u8 bcast_addr[ETH_ALEN] = { 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF };
|
|
|
|
|
2010-06-01 12:19:19 +04:00
|
|
|
static void assert_key_lock(struct ieee80211_local *local)
|
2008-04-08 19:56:52 +04:00
|
|
|
{
|
2010-09-15 15:28:15 +04:00
|
|
|
lockdep_assert_held(&local->key_mtx);
|
2008-04-08 19:56:52 +04:00
|
|
|
}
|
|
|
|
|
2011-06-28 17:11:37 +04:00
|
|
|
static void increment_tailroom_need_count(struct ieee80211_sub_if_data *sdata)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* When this count is zero, SKB resizing for allocating tailroom
|
|
|
|
* for IV or MMIC is skipped. But, this check has created two race
|
|
|
|
* cases in xmit path while transiting from zero count to one:
|
|
|
|
*
|
|
|
|
* 1. SKB resize was skipped because no key was added but just before
|
|
|
|
* the xmit key is added and SW encryption kicks off.
|
|
|
|
*
|
|
|
|
* 2. SKB resize was skipped because all the keys were hw planted but
|
|
|
|
* just before xmit one of the key is deleted and SW encryption kicks
|
|
|
|
* off.
|
|
|
|
*
|
|
|
|
* In both the above case SW encryption will find not enough space for
|
|
|
|
* tailroom and exits with WARN_ON. (See WARN_ONs at wpa.c)
|
|
|
|
*
|
|
|
|
* Solution has been explained at
|
|
|
|
* http://mid.gmane.org/1308590980.4322.19.camel@jlt3.sipsolutions.net
|
|
|
|
*/
|
|
|
|
|
|
|
|
if (!sdata->crypto_tx_tailroom_needed_cnt++) {
|
|
|
|
/*
|
|
|
|
* Flush all XMIT packets currently using HW encryption or no
|
|
|
|
* encryption at all if the count transition is from 0 -> 1.
|
|
|
|
*/
|
|
|
|
synchronize_net();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-08-27 15:26:52 +04:00
|
|
|
static int ieee80211_key_enable_hw_accel(struct ieee80211_key *key)
|
2007-08-29 01:01:55 +04:00
|
|
|
{
|
2008-12-29 14:55:09 +03:00
|
|
|
struct ieee80211_sub_if_data *sdata;
|
2012-01-20 16:55:19 +04:00
|
|
|
struct sta_info *sta;
|
2007-08-29 01:01:55 +04:00
|
|
|
int ret;
|
|
|
|
|
2008-04-08 19:56:52 +04:00
|
|
|
might_sleep();
|
|
|
|
|
2010-10-05 21:39:30 +04:00
|
|
|
if (!key->local->ops->set_key)
|
2010-08-27 15:26:52 +04:00
|
|
|
goto out_unsupported;
|
2007-08-29 01:01:55 +04:00
|
|
|
|
2010-06-01 12:19:19 +04:00
|
|
|
assert_key_lock(key->local);
|
|
|
|
|
2012-01-20 16:55:19 +04:00
|
|
|
sta = key->sta;
|
2008-12-29 14:55:09 +03:00
|
|
|
|
2010-10-05 21:39:30 +04:00
|
|
|
/*
|
|
|
|
* If this is a per-STA GTK, check if it
|
|
|
|
* is supported; if not, return.
|
|
|
|
*/
|
|
|
|
if (sta && !(key->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE) &&
|
|
|
|
!(key->local->hw.flags & IEEE80211_HW_SUPPORTS_PER_STA_GTK))
|
|
|
|
goto out_unsupported;
|
|
|
|
|
2012-01-20 16:55:19 +04:00
|
|
|
if (sta && !sta->uploaded)
|
|
|
|
goto out_unsupported;
|
|
|
|
|
2008-12-29 14:55:09 +03:00
|
|
|
sdata = key->sdata;
|
2010-11-19 10:11:01 +03:00
|
|
|
if (sdata->vif.type == NL80211_IFTYPE_AP_VLAN) {
|
|
|
|
/*
|
|
|
|
* The driver doesn't know anything about VLAN interfaces.
|
|
|
|
* Hence, don't send GTKs for VLAN interfaces to the driver.
|
|
|
|
*/
|
|
|
|
if (!(key->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE))
|
|
|
|
goto out_unsupported;
|
|
|
|
}
|
2007-08-29 01:01:55 +04:00
|
|
|
|
2012-01-20 16:55:19 +04:00
|
|
|
ret = drv_set_key(key->local, SET_KEY, sdata,
|
|
|
|
sta ? &sta->sta : NULL, &key->conf);
|
2007-08-29 01:01:55 +04:00
|
|
|
|
2010-10-05 21:39:30 +04:00
|
|
|
if (!ret) {
|
2007-08-29 01:01:55 +04:00
|
|
|
key->flags |= KEY_FLAG_UPLOADED_TO_HARDWARE;
|
2011-06-28 17:11:37 +04:00
|
|
|
|
|
|
|
if (!((key->conf.flags & IEEE80211_KEY_FLAG_GENERATE_MMIC) ||
|
2011-10-23 10:21:41 +04:00
|
|
|
(key->conf.flags & IEEE80211_KEY_FLAG_GENERATE_IV) ||
|
|
|
|
(key->conf.flags & IEEE80211_KEY_FLAG_PUT_IV_SPACE)))
|
2011-06-28 17:11:37 +04:00
|
|
|
sdata->crypto_tx_tailroom_needed_cnt--;
|
|
|
|
|
2011-10-23 10:21:41 +04:00
|
|
|
WARN_ON((key->conf.flags & IEEE80211_KEY_FLAG_PUT_IV_SPACE) &&
|
|
|
|
(key->conf.flags & IEEE80211_KEY_FLAG_GENERATE_IV));
|
|
|
|
|
2010-10-05 21:39:30 +04:00
|
|
|
return 0;
|
|
|
|
}
|
2007-08-29 01:01:55 +04:00
|
|
|
|
2010-10-05 21:39:30 +04:00
|
|
|
if (ret != -ENOSPC && ret != -EOPNOTSUPP)
|
2012-06-22 13:29:50 +04:00
|
|
|
sdata_err(sdata,
|
2010-08-21 03:25:38 +04:00
|
|
|
"failed to set key (%d, %pM) to hardware (%d)\n",
|
2012-01-20 16:55:19 +04:00
|
|
|
key->conf.keyidx,
|
|
|
|
sta ? sta->sta.addr : bcast_addr, ret);
|
2010-08-27 15:26:52 +04:00
|
|
|
|
2010-10-05 21:39:30 +04:00
|
|
|
out_unsupported:
|
|
|
|
switch (key->conf.cipher) {
|
|
|
|
case WLAN_CIPHER_SUITE_WEP40:
|
|
|
|
case WLAN_CIPHER_SUITE_WEP104:
|
|
|
|
case WLAN_CIPHER_SUITE_TKIP:
|
|
|
|
case WLAN_CIPHER_SUITE_CCMP:
|
|
|
|
case WLAN_CIPHER_SUITE_AES_CMAC:
|
|
|
|
/* all of these we can do in software */
|
|
|
|
return 0;
|
|
|
|
default:
|
|
|
|
return -EINVAL;
|
2010-08-27 15:26:52 +04:00
|
|
|
}
|
2007-08-29 01:01:55 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
static void ieee80211_key_disable_hw_accel(struct ieee80211_key *key)
|
|
|
|
{
|
2008-12-29 14:55:09 +03:00
|
|
|
struct ieee80211_sub_if_data *sdata;
|
2012-01-20 16:55:19 +04:00
|
|
|
struct sta_info *sta;
|
2007-08-29 01:01:55 +04:00
|
|
|
int ret;
|
|
|
|
|
2008-04-08 19:56:52 +04:00
|
|
|
might_sleep();
|
|
|
|
|
2008-02-25 18:27:45 +03:00
|
|
|
if (!key || !key->local->ops->set_key)
|
2007-08-29 01:01:55 +04:00
|
|
|
return;
|
|
|
|
|
2010-06-01 12:19:19 +04:00
|
|
|
assert_key_lock(key->local);
|
|
|
|
|
|
|
|
if (!(key->flags & KEY_FLAG_UPLOADED_TO_HARDWARE))
|
2007-08-29 01:01:55 +04:00
|
|
|
return;
|
|
|
|
|
2012-01-20 16:55:19 +04:00
|
|
|
sta = key->sta;
|
2008-12-29 14:55:09 +03:00
|
|
|
sdata = key->sdata;
|
|
|
|
|
2011-06-28 17:11:37 +04:00
|
|
|
if (!((key->conf.flags & IEEE80211_KEY_FLAG_GENERATE_MMIC) ||
|
2011-10-23 10:21:41 +04:00
|
|
|
(key->conf.flags & IEEE80211_KEY_FLAG_GENERATE_IV) ||
|
|
|
|
(key->conf.flags & IEEE80211_KEY_FLAG_PUT_IV_SPACE)))
|
2011-06-28 17:11:37 +04:00
|
|
|
increment_tailroom_need_count(sdata);
|
|
|
|
|
2009-11-25 22:30:31 +03:00
|
|
|
ret = drv_set_key(key->local, DISABLE_KEY, sdata,
|
2012-01-20 16:55:19 +04:00
|
|
|
sta ? &sta->sta : NULL, &key->conf);
|
2007-08-29 01:01:55 +04:00
|
|
|
|
|
|
|
if (ret)
|
2012-06-22 13:29:50 +04:00
|
|
|
sdata_err(sdata,
|
2010-08-21 03:25:38 +04:00
|
|
|
"failed to remove key (%d, %pM) from hardware (%d)\n",
|
2012-01-20 16:55:19 +04:00
|
|
|
key->conf.keyidx,
|
|
|
|
sta ? sta->sta.addr : bcast_addr, ret);
|
2007-08-29 01:01:55 +04:00
|
|
|
|
2008-04-08 19:56:52 +04:00
|
|
|
key->flags &= ~KEY_FLAG_UPLOADED_TO_HARDWARE;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __ieee80211_set_default_key(struct ieee80211_sub_if_data *sdata,
|
2010-12-09 21:49:02 +03:00
|
|
|
int idx, bool uni, bool multi)
|
2008-04-08 19:56:52 +04:00
|
|
|
{
|
|
|
|
struct ieee80211_key *key = NULL;
|
|
|
|
|
2010-06-01 12:19:19 +04:00
|
|
|
assert_key_lock(sdata->local);
|
|
|
|
|
2008-04-08 19:56:52 +04:00
|
|
|
if (idx >= 0 && idx < NUM_DEFAULT_KEYS)
|
2011-05-13 16:15:49 +04:00
|
|
|
key = key_mtx_dereference(sdata->local, sdata->keys[idx]);
|
2008-04-08 19:56:52 +04:00
|
|
|
|
2012-05-30 12:36:39 +04:00
|
|
|
if (uni) {
|
2010-12-09 21:49:02 +03:00
|
|
|
rcu_assign_pointer(sdata->default_unicast_key, key);
|
2012-05-30 12:36:39 +04:00
|
|
|
drv_set_default_unicast_key(sdata->local, sdata, idx);
|
|
|
|
}
|
|
|
|
|
2010-12-09 21:49:02 +03:00
|
|
|
if (multi)
|
|
|
|
rcu_assign_pointer(sdata->default_multicast_key, key);
|
2008-04-08 19:56:52 +04:00
|
|
|
|
2010-12-09 21:49:02 +03:00
|
|
|
ieee80211_debugfs_key_update_default(sdata);
|
2008-04-08 19:56:52 +04:00
|
|
|
}
|
|
|
|
|
2010-12-09 21:49:02 +03:00
|
|
|
void ieee80211_set_default_key(struct ieee80211_sub_if_data *sdata, int idx,
|
|
|
|
bool uni, bool multi)
|
2008-04-08 19:56:52 +04:00
|
|
|
{
|
2010-06-01 12:19:19 +04:00
|
|
|
mutex_lock(&sdata->local->key_mtx);
|
2010-12-09 21:49:02 +03:00
|
|
|
__ieee80211_set_default_key(sdata, idx, uni, multi);
|
2010-06-01 12:19:19 +04:00
|
|
|
mutex_unlock(&sdata->local->key_mtx);
|
2008-04-08 19:56:52 +04:00
|
|
|
}
|
|
|
|
|
2009-01-08 14:32:02 +03:00
|
|
|
static void
|
|
|
|
__ieee80211_set_default_mgmt_key(struct ieee80211_sub_if_data *sdata, int idx)
|
|
|
|
{
|
|
|
|
struct ieee80211_key *key = NULL;
|
|
|
|
|
2010-06-01 12:19:19 +04:00
|
|
|
assert_key_lock(sdata->local);
|
|
|
|
|
2009-01-08 14:32:02 +03:00
|
|
|
if (idx >= NUM_DEFAULT_KEYS &&
|
|
|
|
idx < NUM_DEFAULT_KEYS + NUM_DEFAULT_MGMT_KEYS)
|
2011-05-13 16:15:49 +04:00
|
|
|
key = key_mtx_dereference(sdata->local, sdata->keys[idx]);
|
2009-01-08 14:32:02 +03:00
|
|
|
|
|
|
|
rcu_assign_pointer(sdata->default_mgmt_key, key);
|
|
|
|
|
2010-12-09 21:49:02 +03:00
|
|
|
ieee80211_debugfs_key_update_default(sdata);
|
2009-01-08 14:32:02 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
void ieee80211_set_default_mgmt_key(struct ieee80211_sub_if_data *sdata,
|
|
|
|
int idx)
|
|
|
|
{
|
2010-06-01 12:19:19 +04:00
|
|
|
mutex_lock(&sdata->local->key_mtx);
|
2009-01-08 14:32:02 +03:00
|
|
|
__ieee80211_set_default_mgmt_key(sdata, idx);
|
2010-06-01 12:19:19 +04:00
|
|
|
mutex_unlock(&sdata->local->key_mtx);
|
2009-01-08 14:32:02 +03:00
|
|
|
}
|
|
|
|
|
2008-04-08 19:56:52 +04:00
|
|
|
|
|
|
|
static void __ieee80211_key_replace(struct ieee80211_sub_if_data *sdata,
|
|
|
|
struct sta_info *sta,
|
2010-10-05 21:39:30 +04:00
|
|
|
bool pairwise,
|
2008-04-08 19:56:52 +04:00
|
|
|
struct ieee80211_key *old,
|
|
|
|
struct ieee80211_key *new)
|
|
|
|
{
|
2010-12-09 21:49:02 +03:00
|
|
|
int idx;
|
|
|
|
bool defunikey, defmultikey, defmgmtkey;
|
2008-04-08 19:56:52 +04:00
|
|
|
|
|
|
|
if (new)
|
2011-07-13 21:50:53 +04:00
|
|
|
list_add_tail(&new->list, &sdata->key_list);
|
2008-04-08 19:56:52 +04:00
|
|
|
|
2010-10-05 21:39:30 +04:00
|
|
|
if (sta && pairwise) {
|
|
|
|
rcu_assign_pointer(sta->ptk, new);
|
|
|
|
} else if (sta) {
|
|
|
|
if (old)
|
|
|
|
idx = old->conf.keyidx;
|
|
|
|
else
|
|
|
|
idx = new->conf.keyidx;
|
|
|
|
rcu_assign_pointer(sta->gtk[idx], new);
|
2008-04-08 19:56:52 +04:00
|
|
|
} else {
|
|
|
|
WARN_ON(new && old && new->conf.keyidx != old->conf.keyidx);
|
|
|
|
|
|
|
|
if (old)
|
|
|
|
idx = old->conf.keyidx;
|
|
|
|
else
|
|
|
|
idx = new->conf.keyidx;
|
|
|
|
|
2011-05-13 16:15:49 +04:00
|
|
|
defunikey = old &&
|
|
|
|
old == key_mtx_dereference(sdata->local,
|
|
|
|
sdata->default_unicast_key);
|
|
|
|
defmultikey = old &&
|
|
|
|
old == key_mtx_dereference(sdata->local,
|
|
|
|
sdata->default_multicast_key);
|
|
|
|
defmgmtkey = old &&
|
|
|
|
old == key_mtx_dereference(sdata->local,
|
|
|
|
sdata->default_mgmt_key);
|
2008-04-08 19:56:52 +04:00
|
|
|
|
2010-12-09 21:49:02 +03:00
|
|
|
if (defunikey && !new)
|
|
|
|
__ieee80211_set_default_key(sdata, -1, true, false);
|
|
|
|
if (defmultikey && !new)
|
|
|
|
__ieee80211_set_default_key(sdata, -1, false, true);
|
2009-01-08 14:32:02 +03:00
|
|
|
if (defmgmtkey && !new)
|
|
|
|
__ieee80211_set_default_mgmt_key(sdata, -1);
|
2008-04-08 19:56:52 +04:00
|
|
|
|
|
|
|
rcu_assign_pointer(sdata->keys[idx], new);
|
2010-12-09 21:49:02 +03:00
|
|
|
if (defunikey && new)
|
|
|
|
__ieee80211_set_default_key(sdata, new->conf.keyidx,
|
|
|
|
true, false);
|
|
|
|
if (defmultikey && new)
|
|
|
|
__ieee80211_set_default_key(sdata, new->conf.keyidx,
|
|
|
|
false, true);
|
2009-01-08 14:32:02 +03:00
|
|
|
if (defmgmtkey && new)
|
|
|
|
__ieee80211_set_default_mgmt_key(sdata,
|
|
|
|
new->conf.keyidx);
|
2008-04-08 19:56:52 +04:00
|
|
|
}
|
|
|
|
|
2011-01-03 21:51:09 +03:00
|
|
|
if (old)
|
|
|
|
list_del(&old->list);
|
2007-08-29 01:01:55 +04:00
|
|
|
}
|
|
|
|
|
2010-08-10 11:46:38 +04:00
|
|
|
struct ieee80211_key *ieee80211_key_alloc(u32 cipher, int idx, size_t key_len,
|
2009-05-11 22:57:58 +04:00
|
|
|
const u8 *key_data,
|
|
|
|
size_t seq_len, const u8 *seq)
|
2007-07-27 17:43:23 +04:00
|
|
|
{
|
|
|
|
struct ieee80211_key *key;
|
2010-08-01 20:37:03 +04:00
|
|
|
int i, j, err;
|
2007-07-27 17:43:23 +04:00
|
|
|
|
2009-01-08 14:32:02 +03:00
|
|
|
BUG_ON(idx < 0 || idx >= NUM_DEFAULT_KEYS + NUM_DEFAULT_MGMT_KEYS);
|
2007-08-29 01:01:55 +04:00
|
|
|
|
|
|
|
key = kzalloc(sizeof(struct ieee80211_key) + key_len, GFP_KERNEL);
|
2007-07-27 17:43:23 +04:00
|
|
|
if (!key)
|
2010-08-01 20:37:03 +04:00
|
|
|
return ERR_PTR(-ENOMEM);
|
2007-08-29 01:01:55 +04:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Default to software encryption; we'll later upload the
|
|
|
|
* key to the hardware if possible.
|
|
|
|
*/
|
|
|
|
key->conf.flags = 0;
|
|
|
|
key->flags = 0;
|
|
|
|
|
2010-08-10 11:46:38 +04:00
|
|
|
key->conf.cipher = cipher;
|
2007-08-29 01:01:55 +04:00
|
|
|
key->conf.keyidx = idx;
|
|
|
|
key->conf.keylen = key_len;
|
2010-08-10 11:46:38 +04:00
|
|
|
switch (cipher) {
|
|
|
|
case WLAN_CIPHER_SUITE_WEP40:
|
|
|
|
case WLAN_CIPHER_SUITE_WEP104:
|
2008-10-05 20:02:48 +04:00
|
|
|
key->conf.iv_len = WEP_IV_LEN;
|
|
|
|
key->conf.icv_len = WEP_ICV_LEN;
|
|
|
|
break;
|
2010-08-10 11:46:38 +04:00
|
|
|
case WLAN_CIPHER_SUITE_TKIP:
|
2008-10-05 20:02:48 +04:00
|
|
|
key->conf.iv_len = TKIP_IV_LEN;
|
|
|
|
key->conf.icv_len = TKIP_ICV_LEN;
|
2009-05-15 13:38:32 +04:00
|
|
|
if (seq) {
|
2012-11-15 02:22:21 +04:00
|
|
|
for (i = 0; i < IEEE80211_NUM_TIDS; i++) {
|
2009-05-11 22:57:58 +04:00
|
|
|
key->u.tkip.rx[i].iv32 =
|
|
|
|
get_unaligned_le32(&seq[2]);
|
|
|
|
key->u.tkip.rx[i].iv16 =
|
|
|
|
get_unaligned_le16(seq);
|
|
|
|
}
|
|
|
|
}
|
mac80211: fix TKIP races, make API easier to use
Our current TKIP code races against itself on TX
since we can process multiple packets at the same
time on different ACs, but they all share the TX
context for TKIP. This can lead to bad IVs etc.
Also, the crypto offload helper code just obtains
the P1K/P2K from the cache, and can update it as
well, but there's no guarantee that packets are
really processed in order.
To fix these issues, first introduce a spinlock
that will protect the IV16/IV32 values in the TX
context. This first step makes sure that we don't
assign the same IV multiple times or get confused
in other ways.
Secondly, change the way the P1K cache works. I
add a field "p1k_iv32" that stores the value of
the IV32 when the P1K was last recomputed, and
if different from the last time, then a new P1K
is recomputed. This can cause the P1K computation
to flip back and forth if packets are processed
out of order. All this also happens under the new
spinlock.
Finally, because there are argument differences,
split up the ieee80211_get_tkip_key() API into
ieee80211_get_tkip_p1k() and ieee80211_get_tkip_p2k()
and give them the correct arguments.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-07-08 00:28:01 +04:00
|
|
|
spin_lock_init(&key->u.tkip.txlock);
|
2008-10-05 20:02:48 +04:00
|
|
|
break;
|
2010-08-10 11:46:38 +04:00
|
|
|
case WLAN_CIPHER_SUITE_CCMP:
|
2008-10-05 20:02:48 +04:00
|
|
|
key->conf.iv_len = CCMP_HDR_LEN;
|
|
|
|
key->conf.icv_len = CCMP_MIC_LEN;
|
2009-05-15 13:38:32 +04:00
|
|
|
if (seq) {
|
2012-11-15 02:22:21 +04:00
|
|
|
for (i = 0; i < IEEE80211_NUM_TIDS + 1; i++)
|
2009-05-11 22:57:58 +04:00
|
|
|
for (j = 0; j < CCMP_PN_LEN; j++)
|
|
|
|
key->u.ccmp.rx_pn[i][j] =
|
|
|
|
seq[CCMP_PN_LEN - j - 1];
|
|
|
|
}
|
2007-08-29 01:01:55 +04:00
|
|
|
/*
|
|
|
|
* Initialize AES key state here as an optimization so that
|
|
|
|
* it does not need to be initialized for every packet.
|
|
|
|
*/
|
|
|
|
key->u.ccmp.tfm = ieee80211_aes_key_setup_encrypt(key_data);
|
2010-08-01 20:37:03 +04:00
|
|
|
if (IS_ERR(key->u.ccmp.tfm)) {
|
|
|
|
err = PTR_ERR(key->u.ccmp.tfm);
|
2008-04-08 19:56:52 +04:00
|
|
|
kfree(key);
|
2011-03-27 15:31:26 +04:00
|
|
|
return ERR_PTR(err);
|
2007-08-29 01:01:55 +04:00
|
|
|
}
|
2010-08-10 11:46:39 +04:00
|
|
|
break;
|
|
|
|
case WLAN_CIPHER_SUITE_AES_CMAC:
|
|
|
|
key->conf.iv_len = 0;
|
|
|
|
key->conf.icv_len = sizeof(struct ieee80211_mmie);
|
|
|
|
if (seq)
|
2012-11-15 02:15:11 +04:00
|
|
|
for (j = 0; j < CMAC_PN_LEN; j++)
|
|
|
|
key->u.aes_cmac.rx_pn[j] =
|
|
|
|
seq[CMAC_PN_LEN - j - 1];
|
2009-01-08 14:32:02 +03:00
|
|
|
/*
|
|
|
|
* Initialize AES key state here as an optimization so that
|
|
|
|
* it does not need to be initialized for every packet.
|
|
|
|
*/
|
|
|
|
key->u.aes_cmac.tfm =
|
|
|
|
ieee80211_aes_cmac_key_setup(key_data);
|
2010-08-01 20:37:03 +04:00
|
|
|
if (IS_ERR(key->u.aes_cmac.tfm)) {
|
|
|
|
err = PTR_ERR(key->u.aes_cmac.tfm);
|
2009-01-08 14:32:02 +03:00
|
|
|
kfree(key);
|
2011-03-27 15:31:26 +04:00
|
|
|
return ERR_PTR(err);
|
2009-01-08 14:32:02 +03:00
|
|
|
}
|
2010-08-10 11:46:39 +04:00
|
|
|
break;
|
2009-01-08 14:32:02 +03:00
|
|
|
}
|
2010-08-10 11:46:39 +04:00
|
|
|
memcpy(key->conf.key, key_data, key_len);
|
|
|
|
INIT_LIST_HEAD(&key->list);
|
2009-01-08 14:32:02 +03:00
|
|
|
|
2008-02-25 18:27:45 +03:00
|
|
|
return key;
|
|
|
|
}
|
2007-08-29 01:01:55 +04:00
|
|
|
|
mac80211: defer tailroom counter manipulation when roaming
During roaming, the crypto_tx_tailroom_needed_cnt counter
will often take values 2,1,0,1,2 because first keys are
removed and then new keys are added. This is inefficient
because during the 0->1 transition, synchronize_net must
be called to avoid packet races, although typically no
packets would be flowing during that time.
To avoid that, defer the decrement (2->1, 1->0) when keys
are removed (by half a second). This means the counter
will really have the values 2,2,2,3,4 ... 2, thus never
reaching 0 and having to do the 0->1 transition.
Note that this patch entirely disregards the drivers for
which this optimisation was done to start with, for them
the key removal itself will be expensive because it has
to synchronize_net() after the counter is incremented to
remove the key from HW crypto. For them the sequence will
look like this: 0,1,0,1,0,1,0,1,0 (*) which is clearly a
lot more inefficient. This could be addressed separately,
during key removal the 0->1->0 sequence isn't necessary.
(*) it starts at 0 because HW crypto is on, then goes to
1 when HW crypto is disabled for a key, then back to
0 because the key is deleted; this happens for both
keys in the example. When new keys are added, it goes
to 1 first because they're added in software; when a
key is moved to hardware it goes back to 0
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-23 03:59:03 +04:00
|
|
|
static void __ieee80211_key_destroy(struct ieee80211_key *key,
|
|
|
|
bool delay_tailroom)
|
2010-06-01 12:19:19 +04:00
|
|
|
{
|
|
|
|
if (!key)
|
|
|
|
return;
|
|
|
|
|
2011-01-03 21:42:24 +03:00
|
|
|
/*
|
|
|
|
* Synchronize so the TX path can no longer be using
|
|
|
|
* this key before we free/remove it.
|
|
|
|
*/
|
2012-09-05 21:23:56 +04:00
|
|
|
synchronize_net();
|
2011-01-03 21:42:24 +03:00
|
|
|
|
2010-07-27 02:52:03 +04:00
|
|
|
if (key->local)
|
|
|
|
ieee80211_key_disable_hw_accel(key);
|
2010-06-01 12:19:19 +04:00
|
|
|
|
2010-08-10 11:46:38 +04:00
|
|
|
if (key->conf.cipher == WLAN_CIPHER_SUITE_CCMP)
|
2010-06-01 12:19:19 +04:00
|
|
|
ieee80211_aes_key_free(key->u.ccmp.tfm);
|
2010-08-10 11:46:38 +04:00
|
|
|
if (key->conf.cipher == WLAN_CIPHER_SUITE_AES_CMAC)
|
2010-06-01 12:19:19 +04:00
|
|
|
ieee80211_aes_cmac_key_free(key->u.aes_cmac.tfm);
|
2011-06-28 17:11:37 +04:00
|
|
|
if (key->local) {
|
mac80211: defer tailroom counter manipulation when roaming
During roaming, the crypto_tx_tailroom_needed_cnt counter
will often take values 2,1,0,1,2 because first keys are
removed and then new keys are added. This is inefficient
because during the 0->1 transition, synchronize_net must
be called to avoid packet races, although typically no
packets would be flowing during that time.
To avoid that, defer the decrement (2->1, 1->0) when keys
are removed (by half a second). This means the counter
will really have the values 2,2,2,3,4 ... 2, thus never
reaching 0 and having to do the 0->1 transition.
Note that this patch entirely disregards the drivers for
which this optimisation was done to start with, for them
the key removal itself will be expensive because it has
to synchronize_net() after the counter is incremented to
remove the key from HW crypto. For them the sequence will
look like this: 0,1,0,1,0,1,0,1,0 (*) which is clearly a
lot more inefficient. This could be addressed separately,
during key removal the 0->1->0 sequence isn't necessary.
(*) it starts at 0 because HW crypto is on, then goes to
1 when HW crypto is disabled for a key, then back to
0 because the key is deleted; this happens for both
keys in the example. When new keys are added, it goes
to 1 first because they're added in software; when a
key is moved to hardware it goes back to 0
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-23 03:59:03 +04:00
|
|
|
struct ieee80211_sub_if_data *sdata = key->sdata;
|
|
|
|
|
2010-07-27 02:52:03 +04:00
|
|
|
ieee80211_debugfs_key_remove(key);
|
mac80211: defer tailroom counter manipulation when roaming
During roaming, the crypto_tx_tailroom_needed_cnt counter
will often take values 2,1,0,1,2 because first keys are
removed and then new keys are added. This is inefficient
because during the 0->1 transition, synchronize_net must
be called to avoid packet races, although typically no
packets would be flowing during that time.
To avoid that, defer the decrement (2->1, 1->0) when keys
are removed (by half a second). This means the counter
will really have the values 2,2,2,3,4 ... 2, thus never
reaching 0 and having to do the 0->1 transition.
Note that this patch entirely disregards the drivers for
which this optimisation was done to start with, for them
the key removal itself will be expensive because it has
to synchronize_net() after the counter is incremented to
remove the key from HW crypto. For them the sequence will
look like this: 0,1,0,1,0,1,0,1,0 (*) which is clearly a
lot more inefficient. This could be addressed separately,
during key removal the 0->1->0 sequence isn't necessary.
(*) it starts at 0 because HW crypto is on, then goes to
1 when HW crypto is disabled for a key, then back to
0 because the key is deleted; this happens for both
keys in the example. When new keys are added, it goes
to 1 first because they're added in software; when a
key is moved to hardware it goes back to 0
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-23 03:59:03 +04:00
|
|
|
|
|
|
|
if (delay_tailroom) {
|
|
|
|
/* see ieee80211_delayed_tailroom_dec */
|
|
|
|
sdata->crypto_tx_tailroom_pending_dec++;
|
|
|
|
schedule_delayed_work(&sdata->dec_tailroom_needed_wk,
|
|
|
|
HZ/2);
|
|
|
|
} else {
|
|
|
|
sdata->crypto_tx_tailroom_needed_cnt--;
|
|
|
|
}
|
2011-06-28 17:11:37 +04:00
|
|
|
}
|
2010-06-01 12:19:19 +04:00
|
|
|
|
|
|
|
kfree(key);
|
|
|
|
}
|
|
|
|
|
2010-08-27 15:26:52 +04:00
|
|
|
int ieee80211_key_link(struct ieee80211_key *key,
|
|
|
|
struct ieee80211_sub_if_data *sdata,
|
|
|
|
struct sta_info *sta)
|
2008-02-25 18:27:45 +03:00
|
|
|
{
|
|
|
|
struct ieee80211_key *old_key;
|
2010-08-27 15:26:52 +04:00
|
|
|
int idx, ret;
|
2011-03-26 20:58:51 +03:00
|
|
|
bool pairwise;
|
2008-02-25 18:27:45 +03:00
|
|
|
|
|
|
|
BUG_ON(!sdata);
|
|
|
|
BUG_ON(!key);
|
|
|
|
|
2011-03-26 20:58:51 +03:00
|
|
|
pairwise = key->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE;
|
2008-02-25 18:27:45 +03:00
|
|
|
idx = key->conf.keyidx;
|
|
|
|
key->local = sdata->local;
|
|
|
|
key->sdata = sdata;
|
|
|
|
key->sta = sta;
|
|
|
|
|
2010-06-01 12:19:19 +04:00
|
|
|
mutex_lock(&sdata->local->key_mtx);
|
2008-04-08 19:56:52 +04:00
|
|
|
|
2010-10-05 21:39:30 +04:00
|
|
|
if (sta && pairwise)
|
2011-05-13 16:15:49 +04:00
|
|
|
old_key = key_mtx_dereference(sdata->local, sta->ptk);
|
2010-10-05 21:39:30 +04:00
|
|
|
else if (sta)
|
2011-05-13 16:15:49 +04:00
|
|
|
old_key = key_mtx_dereference(sdata->local, sta->gtk[idx]);
|
[MAC80211]: fix race conditions with keys
During receive processing, we select the key long before using it and
because there's no locking it is possible that we kfree() the key
after having selected it but before using it for crypto operations.
Obviously, this is bad.
Secondly, during transmit processing, there are two possible races: We
have a similar race between select_key() and using it for encryption,
but we also have a race here between select_key() and hardware
encryption (both when a key is removed.)
This patch solves these issues by using RCU: when a key is to be freed,
we first remove the pointer from the appropriate places (sdata->keys,
sdata->default_key, sta->key) using rcu_assign_pointer() and then
synchronize_rcu(). Then, we can safely kfree() the key and remove it
from the hardware. There's a window here where the hardware may still
be using it for decryption, but we can't work around that without having
two hardware callbacks, one to disable the key for RX and one to disable
it for TX; but the worst thing that will happen is that we receive a
packet decrypted that we don't find a key for any more and then drop it.
When we add a key, we first need to upload it to the hardware and then,
using rcu_assign_pointer() again, link it into our structures.
In the code using keys (TX/RX paths) we use rcu_dereference() to get the
key and enclose the whole tx/rx section in a rcu_read_lock() ...
rcu_read_unlock() block. Because we've uploaded the key to hardware
before linking it into internal structures, we can guarantee that it is
valid once get to into tx().
One possible race condition remains, however: when we have hardware
acceleration enabled and the driver shuts down the queues, we end up
queueing the frame. If now somebody removes the key, the key will be
removed from hwaccel and then then driver will be asked to encrypt the
frame with a key index that has been removed. Hence, drivers will need
to be aware that the hw_key_index they are passed might not be under
all circumstances. Most drivers will, however, simply ignore that
condition and encrypt the frame with the selected key anyway, this
only results in a frame being encrypted with a wrong key or dropped
(rightfully) because the key was not valid. There isn't much we can
do about it unless we want to walk the pending frame queue every time
a key is removed and remove all frames that used it.
This race condition, however, will most likely be solved once we add
multiqueue support to mac80211 because then frames will be queued
further up the stack instead of after being processed.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Acked-by: Michael Wu <flamingice@sourmilk.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-09-14 19:10:24 +04:00
|
|
|
else
|
2011-05-13 16:15:49 +04:00
|
|
|
old_key = key_mtx_dereference(sdata->local, sdata->keys[idx]);
|
2008-02-25 18:27:45 +03:00
|
|
|
|
2011-06-28 17:11:37 +04:00
|
|
|
increment_tailroom_need_count(sdata);
|
|
|
|
|
2010-10-05 21:39:30 +04:00
|
|
|
__ieee80211_key_replace(sdata, sta, pairwise, old_key, key);
|
mac80211: defer tailroom counter manipulation when roaming
During roaming, the crypto_tx_tailroom_needed_cnt counter
will often take values 2,1,0,1,2 because first keys are
removed and then new keys are added. This is inefficient
because during the 0->1 transition, synchronize_net must
be called to avoid packet races, although typically no
packets would be flowing during that time.
To avoid that, defer the decrement (2->1, 1->0) when keys
are removed (by half a second). This means the counter
will really have the values 2,2,2,3,4 ... 2, thus never
reaching 0 and having to do the 0->1 transition.
Note that this patch entirely disregards the drivers for
which this optimisation was done to start with, for them
the key removal itself will be expensive because it has
to synchronize_net() after the counter is incremented to
remove the key from HW crypto. For them the sequence will
look like this: 0,1,0,1,0,1,0,1,0 (*) which is clearly a
lot more inefficient. This could be addressed separately,
during key removal the 0->1->0 sequence isn't necessary.
(*) it starts at 0 because HW crypto is on, then goes to
1 when HW crypto is disabled for a key, then back to
0 because the key is deleted; this happens for both
keys in the example. When new keys are added, it goes
to 1 first because they're added in software; when a
key is moved to hardware it goes back to 0
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-23 03:59:03 +04:00
|
|
|
__ieee80211_key_destroy(old_key, true);
|
[MAC80211]: fix race conditions with keys
During receive processing, we select the key long before using it and
because there's no locking it is possible that we kfree() the key
after having selected it but before using it for crypto operations.
Obviously, this is bad.
Secondly, during transmit processing, there are two possible races: We
have a similar race between select_key() and using it for encryption,
but we also have a race here between select_key() and hardware
encryption (both when a key is removed.)
This patch solves these issues by using RCU: when a key is to be freed,
we first remove the pointer from the appropriate places (sdata->keys,
sdata->default_key, sta->key) using rcu_assign_pointer() and then
synchronize_rcu(). Then, we can safely kfree() the key and remove it
from the hardware. There's a window here where the hardware may still
be using it for decryption, but we can't work around that without having
two hardware callbacks, one to disable the key for RX and one to disable
it for TX; but the worst thing that will happen is that we receive a
packet decrypted that we don't find a key for any more and then drop it.
When we add a key, we first need to upload it to the hardware and then,
using rcu_assign_pointer() again, link it into our structures.
In the code using keys (TX/RX paths) we use rcu_dereference() to get the
key and enclose the whole tx/rx section in a rcu_read_lock() ...
rcu_read_unlock() block. Because we've uploaded the key to hardware
before linking it into internal structures, we can guarantee that it is
valid once get to into tx().
One possible race condition remains, however: when we have hardware
acceleration enabled and the driver shuts down the queues, we end up
queueing the frame. If now somebody removes the key, the key will be
removed from hwaccel and then then driver will be asked to encrypt the
frame with a key index that has been removed. Hence, drivers will need
to be aware that the hw_key_index they are passed might not be under
all circumstances. Most drivers will, however, simply ignore that
condition and encrypt the frame with the selected key anyway, this
only results in a frame being encrypted with a wrong key or dropped
(rightfully) because the key was not valid. There isn't much we can
do about it unless we want to walk the pending frame queue every time
a key is removed and remove all frames that used it.
This race condition, however, will most likely be solved once we add
multiqueue support to mac80211 because then frames will be queued
further up the stack instead of after being processed.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Acked-by: Michael Wu <flamingice@sourmilk.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-09-14 19:10:24 +04:00
|
|
|
|
2010-06-01 12:19:19 +04:00
|
|
|
ieee80211_debugfs_key_add(key);
|
2008-02-25 18:27:45 +03:00
|
|
|
|
2010-08-27 15:26:52 +04:00
|
|
|
ret = ieee80211_key_enable_hw_accel(key);
|
2009-07-01 23:26:43 +04:00
|
|
|
|
2010-06-01 12:19:19 +04:00
|
|
|
mutex_unlock(&sdata->local->key_mtx);
|
2010-08-27 15:26:52 +04:00
|
|
|
|
|
|
|
return ret;
|
2007-07-27 17:43:23 +04:00
|
|
|
}
|
|
|
|
|
mac80211: defer tailroom counter manipulation when roaming
During roaming, the crypto_tx_tailroom_needed_cnt counter
will often take values 2,1,0,1,2 because first keys are
removed and then new keys are added. This is inefficient
because during the 0->1 transition, synchronize_net must
be called to avoid packet races, although typically no
packets would be flowing during that time.
To avoid that, defer the decrement (2->1, 1->0) when keys
are removed (by half a second). This means the counter
will really have the values 2,2,2,3,4 ... 2, thus never
reaching 0 and having to do the 0->1 transition.
Note that this patch entirely disregards the drivers for
which this optimisation was done to start with, for them
the key removal itself will be expensive because it has
to synchronize_net() after the counter is incremented to
remove the key from HW crypto. For them the sequence will
look like this: 0,1,0,1,0,1,0,1,0 (*) which is clearly a
lot more inefficient. This could be addressed separately,
during key removal the 0->1->0 sequence isn't necessary.
(*) it starts at 0 because HW crypto is on, then goes to
1 when HW crypto is disabled for a key, then back to
0 because the key is deleted; this happens for both
keys in the example. When new keys are added, it goes
to 1 first because they're added in software; when a
key is moved to hardware it goes back to 0
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-23 03:59:03 +04:00
|
|
|
void __ieee80211_key_free(struct ieee80211_key *key, bool delay_tailroom)
|
2007-07-27 17:43:23 +04:00
|
|
|
{
|
2011-05-12 16:31:49 +04:00
|
|
|
if (!key)
|
|
|
|
return;
|
|
|
|
|
2008-04-08 19:56:52 +04:00
|
|
|
/*
|
|
|
|
* Replace key with nothingness if it was ever used.
|
|
|
|
*/
|
2008-04-09 18:45:37 +04:00
|
|
|
if (key->sdata)
|
2008-04-08 19:56:52 +04:00
|
|
|
__ieee80211_key_replace(key->sdata, key->sta,
|
2010-10-05 21:39:30 +04:00
|
|
|
key->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE,
|
|
|
|
key, NULL);
|
mac80211: defer tailroom counter manipulation when roaming
During roaming, the crypto_tx_tailroom_needed_cnt counter
will often take values 2,1,0,1,2 because first keys are
removed and then new keys are added. This is inefficient
because during the 0->1 transition, synchronize_net must
be called to avoid packet races, although typically no
packets would be flowing during that time.
To avoid that, defer the decrement (2->1, 1->0) when keys
are removed (by half a second). This means the counter
will really have the values 2,2,2,3,4 ... 2, thus never
reaching 0 and having to do the 0->1 transition.
Note that this patch entirely disregards the drivers for
which this optimisation was done to start with, for them
the key removal itself will be expensive because it has
to synchronize_net() after the counter is incremented to
remove the key from HW crypto. For them the sequence will
look like this: 0,1,0,1,0,1,0,1,0 (*) which is clearly a
lot more inefficient. This could be addressed separately,
during key removal the 0->1->0 sequence isn't necessary.
(*) it starts at 0 because HW crypto is on, then goes to
1 when HW crypto is disabled for a key, then back to
0 because the key is deleted; this happens for both
keys in the example. When new keys are added, it goes
to 1 first because they're added in software; when a
key is moved to hardware it goes back to 0
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-23 03:59:03 +04:00
|
|
|
__ieee80211_key_destroy(key, delay_tailroom);
|
2008-04-08 19:56:52 +04:00
|
|
|
}
|
[MAC80211]: fix race conditions with keys
During receive processing, we select the key long before using it and
because there's no locking it is possible that we kfree() the key
after having selected it but before using it for crypto operations.
Obviously, this is bad.
Secondly, during transmit processing, there are two possible races: We
have a similar race between select_key() and using it for encryption,
but we also have a race here between select_key() and hardware
encryption (both when a key is removed.)
This patch solves these issues by using RCU: when a key is to be freed,
we first remove the pointer from the appropriate places (sdata->keys,
sdata->default_key, sta->key) using rcu_assign_pointer() and then
synchronize_rcu(). Then, we can safely kfree() the key and remove it
from the hardware. There's a window here where the hardware may still
be using it for decryption, but we can't work around that without having
two hardware callbacks, one to disable the key for RX and one to disable
it for TX; but the worst thing that will happen is that we receive a
packet decrypted that we don't find a key for any more and then drop it.
When we add a key, we first need to upload it to the hardware and then,
using rcu_assign_pointer() again, link it into our structures.
In the code using keys (TX/RX paths) we use rcu_dereference() to get the
key and enclose the whole tx/rx section in a rcu_read_lock() ...
rcu_read_unlock() block. Because we've uploaded the key to hardware
before linking it into internal structures, we can guarantee that it is
valid once get to into tx().
One possible race condition remains, however: when we have hardware
acceleration enabled and the driver shuts down the queues, we end up
queueing the frame. If now somebody removes the key, the key will be
removed from hwaccel and then then driver will be asked to encrypt the
frame with a key index that has been removed. Hence, drivers will need
to be aware that the hw_key_index they are passed might not be under
all circumstances. Most drivers will, however, simply ignore that
condition and encrypt the frame with the selected key anyway, this
only results in a frame being encrypted with a wrong key or dropped
(rightfully) because the key was not valid. There isn't much we can
do about it unless we want to walk the pending frame queue every time
a key is removed and remove all frames that used it.
This race condition, however, will most likely be solved once we add
multiqueue support to mac80211 because then frames will be queued
further up the stack instead of after being processed.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Acked-by: Michael Wu <flamingice@sourmilk.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-09-14 19:10:24 +04:00
|
|
|
|
2010-07-27 02:52:03 +04:00
|
|
|
void ieee80211_key_free(struct ieee80211_local *local,
|
|
|
|
struct ieee80211_key *key)
|
2008-04-08 19:56:52 +04:00
|
|
|
{
|
2010-06-01 12:19:19 +04:00
|
|
|
mutex_lock(&local->key_mtx);
|
mac80211: defer tailroom counter manipulation when roaming
During roaming, the crypto_tx_tailroom_needed_cnt counter
will often take values 2,1,0,1,2 because first keys are
removed and then new keys are added. This is inefficient
because during the 0->1 transition, synchronize_net must
be called to avoid packet races, although typically no
packets would be flowing during that time.
To avoid that, defer the decrement (2->1, 1->0) when keys
are removed (by half a second). This means the counter
will really have the values 2,2,2,3,4 ... 2, thus never
reaching 0 and having to do the 0->1 transition.
Note that this patch entirely disregards the drivers for
which this optimisation was done to start with, for them
the key removal itself will be expensive because it has
to synchronize_net() after the counter is incremented to
remove the key from HW crypto. For them the sequence will
look like this: 0,1,0,1,0,1,0,1,0 (*) which is clearly a
lot more inefficient. This could be addressed separately,
during key removal the 0->1->0 sequence isn't necessary.
(*) it starts at 0 because HW crypto is on, then goes to
1 when HW crypto is disabled for a key, then back to
0 because the key is deleted; this happens for both
keys in the example. When new keys are added, it goes
to 1 first because they're added in software; when a
key is moved to hardware it goes back to 0
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-23 03:59:03 +04:00
|
|
|
__ieee80211_key_free(key, true);
|
2010-06-01 12:19:19 +04:00
|
|
|
mutex_unlock(&local->key_mtx);
|
2008-04-09 18:45:37 +04:00
|
|
|
}
|
|
|
|
|
2010-06-01 12:19:19 +04:00
|
|
|
void ieee80211_enable_keys(struct ieee80211_sub_if_data *sdata)
|
2008-04-09 18:45:37 +04:00
|
|
|
{
|
|
|
|
struct ieee80211_key *key;
|
2007-08-29 01:01:55 +04:00
|
|
|
|
2008-04-09 18:45:37 +04:00
|
|
|
ASSERT_RTNL();
|
2007-08-29 01:01:55 +04:00
|
|
|
|
2009-12-23 15:15:31 +03:00
|
|
|
if (WARN_ON(!ieee80211_sdata_running(sdata)))
|
2008-04-09 18:45:37 +04:00
|
|
|
return;
|
2007-08-29 01:01:55 +04:00
|
|
|
|
2010-06-01 12:19:19 +04:00
|
|
|
mutex_lock(&sdata->local->key_mtx);
|
2007-08-29 01:01:55 +04:00
|
|
|
|
2011-06-28 17:11:37 +04:00
|
|
|
sdata->crypto_tx_tailroom_needed_cnt = 0;
|
|
|
|
|
|
|
|
list_for_each_entry(key, &sdata->key_list, list) {
|
|
|
|
increment_tailroom_need_count(sdata);
|
2010-06-01 12:19:19 +04:00
|
|
|
ieee80211_key_enable_hw_accel(key);
|
2011-06-28 17:11:37 +04:00
|
|
|
}
|
2008-04-08 19:56:52 +04:00
|
|
|
|
2010-06-01 12:19:19 +04:00
|
|
|
mutex_unlock(&sdata->local->key_mtx);
|
2007-08-29 01:01:55 +04:00
|
|
|
}
|
|
|
|
|
2011-07-05 18:35:39 +04:00
|
|
|
void ieee80211_iter_keys(struct ieee80211_hw *hw,
|
|
|
|
struct ieee80211_vif *vif,
|
|
|
|
void (*iter)(struct ieee80211_hw *hw,
|
|
|
|
struct ieee80211_vif *vif,
|
|
|
|
struct ieee80211_sta *sta,
|
|
|
|
struct ieee80211_key_conf *key,
|
|
|
|
void *data),
|
|
|
|
void *iter_data)
|
|
|
|
{
|
|
|
|
struct ieee80211_local *local = hw_to_local(hw);
|
|
|
|
struct ieee80211_key *key;
|
|
|
|
struct ieee80211_sub_if_data *sdata;
|
|
|
|
|
|
|
|
ASSERT_RTNL();
|
|
|
|
|
|
|
|
mutex_lock(&local->key_mtx);
|
|
|
|
if (vif) {
|
|
|
|
sdata = vif_to_sdata(vif);
|
|
|
|
list_for_each_entry(key, &sdata->key_list, list)
|
|
|
|
iter(hw, &sdata->vif,
|
|
|
|
key->sta ? &key->sta->sta : NULL,
|
|
|
|
&key->conf, iter_data);
|
|
|
|
} else {
|
|
|
|
list_for_each_entry(sdata, &local->interfaces, list)
|
|
|
|
list_for_each_entry(key, &sdata->key_list, list)
|
|
|
|
iter(hw, &sdata->vif,
|
|
|
|
key->sta ? &key->sta->sta : NULL,
|
|
|
|
&key->conf, iter_data);
|
|
|
|
}
|
|
|
|
mutex_unlock(&local->key_mtx);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(ieee80211_iter_keys);
|
|
|
|
|
2008-04-08 19:56:52 +04:00
|
|
|
void ieee80211_free_keys(struct ieee80211_sub_if_data *sdata)
|
|
|
|
{
|
|
|
|
struct ieee80211_key *key, *tmp;
|
2008-02-25 18:27:45 +03:00
|
|
|
|
mac80211: defer tailroom counter manipulation when roaming
During roaming, the crypto_tx_tailroom_needed_cnt counter
will often take values 2,1,0,1,2 because first keys are
removed and then new keys are added. This is inefficient
because during the 0->1 transition, synchronize_net must
be called to avoid packet races, although typically no
packets would be flowing during that time.
To avoid that, defer the decrement (2->1, 1->0) when keys
are removed (by half a second). This means the counter
will really have the values 2,2,2,3,4 ... 2, thus never
reaching 0 and having to do the 0->1 transition.
Note that this patch entirely disregards the drivers for
which this optimisation was done to start with, for them
the key removal itself will be expensive because it has
to synchronize_net() after the counter is incremented to
remove the key from HW crypto. For them the sequence will
look like this: 0,1,0,1,0,1,0,1,0 (*) which is clearly a
lot more inefficient. This could be addressed separately,
during key removal the 0->1->0 sequence isn't necessary.
(*) it starts at 0 because HW crypto is on, then goes to
1 when HW crypto is disabled for a key, then back to
0 because the key is deleted; this happens for both
keys in the example. When new keys are added, it goes
to 1 first because they're added in software; when a
key is moved to hardware it goes back to 0
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-23 03:59:03 +04:00
|
|
|
cancel_delayed_work_sync(&sdata->dec_tailroom_needed_wk);
|
|
|
|
|
2010-06-01 12:19:19 +04:00
|
|
|
mutex_lock(&sdata->local->key_mtx);
|
2008-04-08 19:56:52 +04:00
|
|
|
|
mac80211: defer tailroom counter manipulation when roaming
During roaming, the crypto_tx_tailroom_needed_cnt counter
will often take values 2,1,0,1,2 because first keys are
removed and then new keys are added. This is inefficient
because during the 0->1 transition, synchronize_net must
be called to avoid packet races, although typically no
packets would be flowing during that time.
To avoid that, defer the decrement (2->1, 1->0) when keys
are removed (by half a second). This means the counter
will really have the values 2,2,2,3,4 ... 2, thus never
reaching 0 and having to do the 0->1 transition.
Note that this patch entirely disregards the drivers for
which this optimisation was done to start with, for them
the key removal itself will be expensive because it has
to synchronize_net() after the counter is incremented to
remove the key from HW crypto. For them the sequence will
look like this: 0,1,0,1,0,1,0,1,0 (*) which is clearly a
lot more inefficient. This could be addressed separately,
during key removal the 0->1->0 sequence isn't necessary.
(*) it starts at 0 because HW crypto is on, then goes to
1 when HW crypto is disabled for a key, then back to
0 because the key is deleted; this happens for both
keys in the example. When new keys are added, it goes
to 1 first because they're added in software; when a
key is moved to hardware it goes back to 0
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-23 03:59:03 +04:00
|
|
|
sdata->crypto_tx_tailroom_needed_cnt -=
|
|
|
|
sdata->crypto_tx_tailroom_pending_dec;
|
|
|
|
sdata->crypto_tx_tailroom_pending_dec = 0;
|
|
|
|
|
2009-01-08 14:32:02 +03:00
|
|
|
ieee80211_debugfs_key_remove_mgmt_default(sdata);
|
2008-04-08 19:56:52 +04:00
|
|
|
|
|
|
|
list_for_each_entry_safe(key, tmp, &sdata->key_list, list)
|
mac80211: defer tailroom counter manipulation when roaming
During roaming, the crypto_tx_tailroom_needed_cnt counter
will often take values 2,1,0,1,2 because first keys are
removed and then new keys are added. This is inefficient
because during the 0->1 transition, synchronize_net must
be called to avoid packet races, although typically no
packets would be flowing during that time.
To avoid that, defer the decrement (2->1, 1->0) when keys
are removed (by half a second). This means the counter
will really have the values 2,2,2,3,4 ... 2, thus never
reaching 0 and having to do the 0->1 transition.
Note that this patch entirely disregards the drivers for
which this optimisation was done to start with, for them
the key removal itself will be expensive because it has
to synchronize_net() after the counter is incremented to
remove the key from HW crypto. For them the sequence will
look like this: 0,1,0,1,0,1,0,1,0 (*) which is clearly a
lot more inefficient. This could be addressed separately,
during key removal the 0->1->0 sequence isn't necessary.
(*) it starts at 0 because HW crypto is on, then goes to
1 when HW crypto is disabled for a key, then back to
0 because the key is deleted; this happens for both
keys in the example. When new keys are added, it goes
to 1 first because they're added in software; when a
key is moved to hardware it goes back to 0
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-23 03:59:03 +04:00
|
|
|
__ieee80211_key_free(key, false);
|
2008-04-08 19:56:52 +04:00
|
|
|
|
2010-12-09 21:49:02 +03:00
|
|
|
ieee80211_debugfs_key_update_default(sdata);
|
|
|
|
|
mac80211: defer tailroom counter manipulation when roaming
During roaming, the crypto_tx_tailroom_needed_cnt counter
will often take values 2,1,0,1,2 because first keys are
removed and then new keys are added. This is inefficient
because during the 0->1 transition, synchronize_net must
be called to avoid packet races, although typically no
packets would be flowing during that time.
To avoid that, defer the decrement (2->1, 1->0) when keys
are removed (by half a second). This means the counter
will really have the values 2,2,2,3,4 ... 2, thus never
reaching 0 and having to do the 0->1 transition.
Note that this patch entirely disregards the drivers for
which this optimisation was done to start with, for them
the key removal itself will be expensive because it has
to synchronize_net() after the counter is incremented to
remove the key from HW crypto. For them the sequence will
look like this: 0,1,0,1,0,1,0,1,0 (*) which is clearly a
lot more inefficient. This could be addressed separately,
during key removal the 0->1->0 sequence isn't necessary.
(*) it starts at 0 because HW crypto is on, then goes to
1 when HW crypto is disabled for a key, then back to
0 because the key is deleted; this happens for both
keys in the example. When new keys are added, it goes
to 1 first because they're added in software; when a
key is moved to hardware it goes back to 0
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-23 03:59:03 +04:00
|
|
|
WARN_ON_ONCE(sdata->crypto_tx_tailroom_needed_cnt ||
|
|
|
|
sdata->crypto_tx_tailroom_pending_dec);
|
|
|
|
|
2010-06-01 12:19:19 +04:00
|
|
|
mutex_unlock(&sdata->local->key_mtx);
|
2007-08-29 01:01:55 +04:00
|
|
|
}
|
2011-07-05 18:35:41 +04:00
|
|
|
|
mac80211: defer tailroom counter manipulation when roaming
During roaming, the crypto_tx_tailroom_needed_cnt counter
will often take values 2,1,0,1,2 because first keys are
removed and then new keys are added. This is inefficient
because during the 0->1 transition, synchronize_net must
be called to avoid packet races, although typically no
packets would be flowing during that time.
To avoid that, defer the decrement (2->1, 1->0) when keys
are removed (by half a second). This means the counter
will really have the values 2,2,2,3,4 ... 2, thus never
reaching 0 and having to do the 0->1 transition.
Note that this patch entirely disregards the drivers for
which this optimisation was done to start with, for them
the key removal itself will be expensive because it has
to synchronize_net() after the counter is incremented to
remove the key from HW crypto. For them the sequence will
look like this: 0,1,0,1,0,1,0,1,0 (*) which is clearly a
lot more inefficient. This could be addressed separately,
during key removal the 0->1->0 sequence isn't necessary.
(*) it starts at 0 because HW crypto is on, then goes to
1 when HW crypto is disabled for a key, then back to
0 because the key is deleted; this happens for both
keys in the example. When new keys are added, it goes
to 1 first because they're added in software; when a
key is moved to hardware it goes back to 0
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-23 03:59:03 +04:00
|
|
|
void ieee80211_delayed_tailroom_dec(struct work_struct *wk)
|
|
|
|
{
|
|
|
|
struct ieee80211_sub_if_data *sdata;
|
|
|
|
|
|
|
|
sdata = container_of(wk, struct ieee80211_sub_if_data,
|
|
|
|
dec_tailroom_needed_wk.work);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The reason for the delayed tailroom needed decrementing is to
|
|
|
|
* make roaming faster: during roaming, all keys are first deleted
|
|
|
|
* and then new keys are installed. The first new key causes the
|
|
|
|
* crypto_tx_tailroom_needed_cnt to go from 0 to 1, which invokes
|
|
|
|
* the cost of synchronize_net() (which can be slow). Avoid this
|
|
|
|
* by deferring the crypto_tx_tailroom_needed_cnt decrementing on
|
|
|
|
* key removal for a while, so if we roam the value is larger than
|
|
|
|
* zero and no 0->1 transition happens.
|
|
|
|
*
|
|
|
|
* The cost is that if the AP switching was from an AP with keys
|
|
|
|
* to one without, we still allocate tailroom while it would no
|
|
|
|
* longer be needed. However, in the typical (fast) roaming case
|
|
|
|
* within an ESS this usually won't happen.
|
|
|
|
*/
|
|
|
|
|
|
|
|
mutex_lock(&sdata->local->key_mtx);
|
|
|
|
sdata->crypto_tx_tailroom_needed_cnt -=
|
|
|
|
sdata->crypto_tx_tailroom_pending_dec;
|
|
|
|
sdata->crypto_tx_tailroom_pending_dec = 0;
|
|
|
|
mutex_unlock(&sdata->local->key_mtx);
|
|
|
|
}
|
2011-07-05 18:35:41 +04:00
|
|
|
|
|
|
|
void ieee80211_gtk_rekey_notify(struct ieee80211_vif *vif, const u8 *bssid,
|
|
|
|
const u8 *replay_ctr, gfp_t gfp)
|
|
|
|
{
|
|
|
|
struct ieee80211_sub_if_data *sdata = vif_to_sdata(vif);
|
|
|
|
|
|
|
|
trace_api_gtk_rekey_notify(sdata, bssid, replay_ctr);
|
|
|
|
|
|
|
|
cfg80211_gtk_rekey_notify(sdata->dev, bssid, replay_ctr, gfp);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(ieee80211_gtk_rekey_notify);
|
2011-07-07 20:58:00 +04:00
|
|
|
|
|
|
|
void ieee80211_get_key_tx_seq(struct ieee80211_key_conf *keyconf,
|
|
|
|
struct ieee80211_key_seq *seq)
|
|
|
|
{
|
|
|
|
struct ieee80211_key *key;
|
|
|
|
u64 pn64;
|
|
|
|
|
|
|
|
if (WARN_ON(!(keyconf->flags & IEEE80211_KEY_FLAG_GENERATE_IV)))
|
|
|
|
return;
|
|
|
|
|
|
|
|
key = container_of(keyconf, struct ieee80211_key, conf);
|
|
|
|
|
|
|
|
switch (key->conf.cipher) {
|
|
|
|
case WLAN_CIPHER_SUITE_TKIP:
|
|
|
|
seq->tkip.iv32 = key->u.tkip.tx.iv32;
|
|
|
|
seq->tkip.iv16 = key->u.tkip.tx.iv16;
|
|
|
|
break;
|
|
|
|
case WLAN_CIPHER_SUITE_CCMP:
|
|
|
|
pn64 = atomic64_read(&key->u.ccmp.tx_pn);
|
|
|
|
seq->ccmp.pn[5] = pn64;
|
|
|
|
seq->ccmp.pn[4] = pn64 >> 8;
|
|
|
|
seq->ccmp.pn[3] = pn64 >> 16;
|
|
|
|
seq->ccmp.pn[2] = pn64 >> 24;
|
|
|
|
seq->ccmp.pn[1] = pn64 >> 32;
|
|
|
|
seq->ccmp.pn[0] = pn64 >> 40;
|
|
|
|
break;
|
|
|
|
case WLAN_CIPHER_SUITE_AES_CMAC:
|
|
|
|
pn64 = atomic64_read(&key->u.aes_cmac.tx_pn);
|
|
|
|
seq->ccmp.pn[5] = pn64;
|
|
|
|
seq->ccmp.pn[4] = pn64 >> 8;
|
|
|
|
seq->ccmp.pn[3] = pn64 >> 16;
|
|
|
|
seq->ccmp.pn[2] = pn64 >> 24;
|
|
|
|
seq->ccmp.pn[1] = pn64 >> 32;
|
|
|
|
seq->ccmp.pn[0] = pn64 >> 40;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
WARN_ON(1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(ieee80211_get_key_tx_seq);
|
|
|
|
|
|
|
|
void ieee80211_get_key_rx_seq(struct ieee80211_key_conf *keyconf,
|
|
|
|
int tid, struct ieee80211_key_seq *seq)
|
|
|
|
{
|
|
|
|
struct ieee80211_key *key;
|
|
|
|
const u8 *pn;
|
|
|
|
|
|
|
|
key = container_of(keyconf, struct ieee80211_key, conf);
|
|
|
|
|
|
|
|
switch (key->conf.cipher) {
|
|
|
|
case WLAN_CIPHER_SUITE_TKIP:
|
2012-11-15 02:22:21 +04:00
|
|
|
if (WARN_ON(tid < 0 || tid >= IEEE80211_NUM_TIDS))
|
2011-07-07 20:58:00 +04:00
|
|
|
return;
|
|
|
|
seq->tkip.iv32 = key->u.tkip.rx[tid].iv32;
|
|
|
|
seq->tkip.iv16 = key->u.tkip.rx[tid].iv16;
|
|
|
|
break;
|
|
|
|
case WLAN_CIPHER_SUITE_CCMP:
|
2012-11-15 02:22:21 +04:00
|
|
|
if (WARN_ON(tid < -1 || tid >= IEEE80211_NUM_TIDS))
|
2011-07-07 20:58:00 +04:00
|
|
|
return;
|
|
|
|
if (tid < 0)
|
2012-11-15 02:22:21 +04:00
|
|
|
pn = key->u.ccmp.rx_pn[IEEE80211_NUM_TIDS];
|
2011-07-07 20:58:00 +04:00
|
|
|
else
|
|
|
|
pn = key->u.ccmp.rx_pn[tid];
|
|
|
|
memcpy(seq->ccmp.pn, pn, CCMP_PN_LEN);
|
|
|
|
break;
|
|
|
|
case WLAN_CIPHER_SUITE_AES_CMAC:
|
|
|
|
if (WARN_ON(tid != 0))
|
|
|
|
return;
|
|
|
|
pn = key->u.aes_cmac.rx_pn;
|
|
|
|
memcpy(seq->aes_cmac.pn, pn, CMAC_PN_LEN);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(ieee80211_get_key_rx_seq);
|