2007-07-27 09: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 11:56:52 -04:00
|
|
|
* Copyright 2007-2008 Johannes Berg <johannes@sipsolutions.net>
|
2007-07-27 09: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-28 17: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 11:10:24 -04:00
|
|
|
#include <linux/rcupdate.h>
|
2008-02-25 10:27:45 -05:00
|
|
|
#include <linux/rtnetlink.h>
|
2007-07-27 09:43:23 -04:00
|
|
|
#include <net/mac80211.h>
|
|
|
|
#include "ieee80211_i.h"
|
|
|
|
#include "debugfs_key.h"
|
|
|
|
#include "aes_ccm.h"
|
|
|
|
|
2007-08-28 17:01:55 -04:00
|
|
|
|
2008-02-26 08:34:06 -05:00
|
|
|
/**
|
|
|
|
* DOC: Key handling basics
|
2007-08-28 17: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.
|
|
|
|
*
|
|
|
|
* Hardware acceleration is done on a best-effort basis, for each key
|
|
|
|
* that is eligible the hardware is asked to enable that key but if
|
|
|
|
* it cannot do that they key is simply kept for software encryption.
|
|
|
|
* There is currently no way of knowing this except by looking into
|
|
|
|
* debugfs.
|
|
|
|
*
|
2008-04-08 11:56:52 -04:00
|
|
|
* All key operations are protected internally so you can call them at
|
|
|
|
* any time.
|
2008-02-25 10:27:45 -05:00
|
|
|
*
|
2008-04-08 11:56:52 -04:00
|
|
|
* Within 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 flush the key todo
|
|
|
|
* list.
|
|
|
|
*
|
|
|
|
* All the direct key list manipulation functions must not sleep because
|
|
|
|
* they can operate on STA info structs that are protected by RCU.
|
2007-08-28 17:01:55 -04:00
|
|
|
*/
|
|
|
|
|
|
|
|
static const u8 bcast_addr[ETH_ALEN] = { 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF };
|
|
|
|
static const u8 zero_addr[ETH_ALEN];
|
|
|
|
|
2008-04-08 11:56:52 -04:00
|
|
|
/* key mutex: used to synchronise todo runners */
|
|
|
|
static DEFINE_MUTEX(key_mutex);
|
|
|
|
static DEFINE_SPINLOCK(todo_lock);
|
|
|
|
static LIST_HEAD(todo_list);
|
|
|
|
|
|
|
|
static void key_todo(struct work_struct *work)
|
|
|
|
{
|
|
|
|
ieee80211_key_todo();
|
|
|
|
}
|
|
|
|
|
|
|
|
static DECLARE_WORK(todo_work, key_todo);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* add_todo - add todo item for a key
|
|
|
|
*
|
|
|
|
* @key: key to add to do item for
|
|
|
|
* @flag: todo flag(s)
|
|
|
|
*/
|
|
|
|
static void add_todo(struct ieee80211_key *key, u32 flag)
|
|
|
|
{
|
|
|
|
if (!key)
|
|
|
|
return;
|
|
|
|
|
|
|
|
spin_lock(&todo_lock);
|
|
|
|
key->flags |= flag;
|
|
|
|
/* only add if not already added */
|
|
|
|
if (list_empty(&key->todo))
|
|
|
|
list_add(&key->todo, &todo_list);
|
|
|
|
schedule_work(&todo_work);
|
|
|
|
spin_unlock(&todo_lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ieee80211_key_lock - lock the mac80211 key operation lock
|
|
|
|
*
|
|
|
|
* This locks the (global) mac80211 key operation lock, all
|
|
|
|
* key operations must be done under this lock.
|
|
|
|
*/
|
|
|
|
static void ieee80211_key_lock(void)
|
|
|
|
{
|
|
|
|
mutex_lock(&key_mutex);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ieee80211_key_unlock - unlock the mac80211 key operation lock
|
|
|
|
*/
|
|
|
|
static void ieee80211_key_unlock(void)
|
|
|
|
{
|
|
|
|
mutex_unlock(&key_mutex);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void assert_key_lock(void)
|
|
|
|
{
|
|
|
|
WARN_ON(!mutex_is_locked(&key_mutex));
|
|
|
|
}
|
|
|
|
|
2007-08-28 17:01:55 -04:00
|
|
|
static const u8 *get_mac_for_key(struct ieee80211_key *key)
|
|
|
|
{
|
|
|
|
const u8 *addr = bcast_addr;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If we're an AP we won't ever receive frames with a non-WEP
|
|
|
|
* group key so we tell the driver that by using the zero MAC
|
|
|
|
* address to indicate a transmit-only key.
|
|
|
|
*/
|
|
|
|
if (key->conf.alg != ALG_WEP &&
|
2007-12-18 19:31:27 -05:00
|
|
|
(key->sdata->vif.type == IEEE80211_IF_TYPE_AP ||
|
|
|
|
key->sdata->vif.type == IEEE80211_IF_TYPE_VLAN))
|
2007-08-28 17:01:55 -04:00
|
|
|
addr = zero_addr;
|
|
|
|
|
|
|
|
if (key->sta)
|
|
|
|
addr = key->sta->addr;
|
|
|
|
|
|
|
|
return addr;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void ieee80211_key_enable_hw_accel(struct ieee80211_key *key)
|
|
|
|
{
|
|
|
|
const u8 *addr;
|
|
|
|
int ret;
|
2007-10-03 20:59:30 -04:00
|
|
|
DECLARE_MAC_BUF(mac);
|
2007-08-28 17:01:55 -04:00
|
|
|
|
2008-04-08 11:56:52 -04:00
|
|
|
assert_key_lock();
|
|
|
|
might_sleep();
|
|
|
|
|
2007-08-28 17:01:55 -04:00
|
|
|
if (!key->local->ops->set_key)
|
|
|
|
return;
|
|
|
|
|
|
|
|
addr = get_mac_for_key(key);
|
|
|
|
|
|
|
|
ret = key->local->ops->set_key(local_to_hw(key->local), SET_KEY,
|
|
|
|
key->sdata->dev->dev_addr, addr,
|
|
|
|
&key->conf);
|
|
|
|
|
2008-04-08 11:56:52 -04:00
|
|
|
if (!ret) {
|
|
|
|
spin_lock(&todo_lock);
|
2007-08-28 17:01:55 -04:00
|
|
|
key->flags |= KEY_FLAG_UPLOADED_TO_HARDWARE;
|
2008-04-08 11:56:52 -04:00
|
|
|
spin_unlock(&todo_lock);
|
|
|
|
}
|
2007-08-28 17:01:55 -04:00
|
|
|
|
|
|
|
if (ret && ret != -ENOSPC && ret != -EOPNOTSUPP)
|
|
|
|
printk(KERN_ERR "mac80211-%s: failed to set key "
|
2007-10-03 20:59:30 -04:00
|
|
|
"(%d, %s) to hardware (%d)\n",
|
2007-08-28 17:01:55 -04:00
|
|
|
wiphy_name(key->local->hw.wiphy),
|
2007-10-03 20:59:30 -04:00
|
|
|
key->conf.keyidx, print_mac(mac, addr), ret);
|
2007-08-28 17:01:55 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
static void ieee80211_key_disable_hw_accel(struct ieee80211_key *key)
|
|
|
|
{
|
|
|
|
const u8 *addr;
|
|
|
|
int ret;
|
2007-10-03 20:59:30 -04:00
|
|
|
DECLARE_MAC_BUF(mac);
|
2007-08-28 17:01:55 -04:00
|
|
|
|
2008-04-08 11:56:52 -04:00
|
|
|
assert_key_lock();
|
|
|
|
might_sleep();
|
|
|
|
|
2008-02-25 10:27:45 -05:00
|
|
|
if (!key || !key->local->ops->set_key)
|
2007-08-28 17:01:55 -04:00
|
|
|
return;
|
|
|
|
|
2008-04-08 11:56:52 -04:00
|
|
|
spin_lock(&todo_lock);
|
|
|
|
if (!(key->flags & KEY_FLAG_UPLOADED_TO_HARDWARE)) {
|
|
|
|
spin_unlock(&todo_lock);
|
2007-08-28 17:01:55 -04:00
|
|
|
return;
|
2008-04-08 11:56:52 -04:00
|
|
|
}
|
|
|
|
spin_unlock(&todo_lock);
|
2007-08-28 17:01:55 -04:00
|
|
|
|
|
|
|
addr = get_mac_for_key(key);
|
|
|
|
|
|
|
|
ret = key->local->ops->set_key(local_to_hw(key->local), DISABLE_KEY,
|
|
|
|
key->sdata->dev->dev_addr, addr,
|
|
|
|
&key->conf);
|
|
|
|
|
|
|
|
if (ret)
|
|
|
|
printk(KERN_ERR "mac80211-%s: failed to remove key "
|
2007-10-03 20:59:30 -04:00
|
|
|
"(%d, %s) from hardware (%d)\n",
|
2007-08-28 17:01:55 -04:00
|
|
|
wiphy_name(key->local->hw.wiphy),
|
2007-10-03 20:59:30 -04:00
|
|
|
key->conf.keyidx, print_mac(mac, addr), ret);
|
2007-08-28 17:01:55 -04:00
|
|
|
|
2008-04-08 11:56:52 -04:00
|
|
|
spin_lock(&todo_lock);
|
|
|
|
key->flags &= ~KEY_FLAG_UPLOADED_TO_HARDWARE;
|
|
|
|
spin_unlock(&todo_lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __ieee80211_set_default_key(struct ieee80211_sub_if_data *sdata,
|
|
|
|
int idx)
|
|
|
|
{
|
|
|
|
struct ieee80211_key *key = NULL;
|
|
|
|
|
|
|
|
if (idx >= 0 && idx < NUM_DEFAULT_KEYS)
|
|
|
|
key = sdata->keys[idx];
|
|
|
|
|
|
|
|
rcu_assign_pointer(sdata->default_key, key);
|
|
|
|
|
|
|
|
if (key)
|
|
|
|
add_todo(key, KEY_FLAG_TODO_DEFKEY);
|
|
|
|
}
|
|
|
|
|
|
|
|
void ieee80211_set_default_key(struct ieee80211_sub_if_data *sdata, int idx)
|
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
spin_lock_irqsave(&sdata->local->sta_lock, flags);
|
|
|
|
__ieee80211_set_default_key(sdata, idx);
|
|
|
|
spin_unlock_irqrestore(&sdata->local->sta_lock, flags);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
static void __ieee80211_key_replace(struct ieee80211_sub_if_data *sdata,
|
|
|
|
struct sta_info *sta,
|
|
|
|
struct ieee80211_key *old,
|
|
|
|
struct ieee80211_key *new)
|
|
|
|
{
|
|
|
|
int idx, defkey;
|
|
|
|
|
|
|
|
if (new)
|
|
|
|
list_add(&new->list, &sdata->key_list);
|
|
|
|
|
|
|
|
if (sta) {
|
|
|
|
rcu_assign_pointer(sta->key, new);
|
|
|
|
} else {
|
|
|
|
WARN_ON(new && old && new->conf.keyidx != old->conf.keyidx);
|
|
|
|
|
|
|
|
if (old)
|
|
|
|
idx = old->conf.keyidx;
|
|
|
|
else
|
|
|
|
idx = new->conf.keyidx;
|
|
|
|
|
|
|
|
defkey = old && sdata->default_key == old;
|
|
|
|
|
|
|
|
if (defkey && !new)
|
|
|
|
__ieee80211_set_default_key(sdata, -1);
|
|
|
|
|
|
|
|
rcu_assign_pointer(sdata->keys[idx], new);
|
|
|
|
if (defkey && new)
|
|
|
|
__ieee80211_set_default_key(sdata, new->conf.keyidx);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (old) {
|
|
|
|
/*
|
|
|
|
* We'll use an empty list to indicate that the key
|
|
|
|
* has already been removed.
|
|
|
|
*/
|
|
|
|
list_del_init(&old->list);
|
|
|
|
}
|
2007-08-28 17:01:55 -04:00
|
|
|
}
|
|
|
|
|
2008-02-25 10:27:45 -05:00
|
|
|
struct ieee80211_key *ieee80211_key_alloc(enum ieee80211_key_alg alg,
|
2007-08-28 17:01:55 -04:00
|
|
|
int idx,
|
|
|
|
size_t key_len,
|
|
|
|
const u8 *key_data)
|
2007-07-27 09:43:23 -04:00
|
|
|
{
|
|
|
|
struct ieee80211_key *key;
|
|
|
|
|
[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 11:10:24 -04:00
|
|
|
BUG_ON(idx < 0 || idx >= NUM_DEFAULT_KEYS);
|
2007-08-28 17:01:55 -04:00
|
|
|
|
|
|
|
key = kzalloc(sizeof(struct ieee80211_key) + key_len, GFP_KERNEL);
|
2007-07-27 09:43:23 -04:00
|
|
|
if (!key)
|
|
|
|
return NULL;
|
2007-08-28 17: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;
|
|
|
|
|
|
|
|
key->conf.alg = alg;
|
|
|
|
key->conf.keyidx = idx;
|
|
|
|
key->conf.keylen = key_len;
|
|
|
|
memcpy(key->conf.key, key_data, key_len);
|
2008-02-27 07:39:00 -05:00
|
|
|
INIT_LIST_HEAD(&key->list);
|
2008-04-08 11:56:52 -04:00
|
|
|
INIT_LIST_HEAD(&key->todo);
|
2007-08-28 17:01:55 -04:00
|
|
|
|
|
|
|
if (alg == ALG_CCMP) {
|
|
|
|
/*
|
|
|
|
* 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);
|
|
|
|
if (!key->u.ccmp.tfm) {
|
2008-04-08 11:56:52 -04:00
|
|
|
kfree(key);
|
2007-08-28 17:01:55 -04:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-02-25 10:27:45 -05:00
|
|
|
return key;
|
|
|
|
}
|
2007-08-28 17:01:55 -04:00
|
|
|
|
2008-02-25 10:27:45 -05:00
|
|
|
void ieee80211_key_link(struct ieee80211_key *key,
|
|
|
|
struct ieee80211_sub_if_data *sdata,
|
|
|
|
struct sta_info *sta)
|
|
|
|
{
|
|
|
|
struct ieee80211_key *old_key;
|
2008-04-08 11:56:52 -04:00
|
|
|
unsigned long flags;
|
2008-02-25 10:27:45 -05:00
|
|
|
int idx;
|
|
|
|
|
|
|
|
BUG_ON(!sdata);
|
|
|
|
BUG_ON(!key);
|
|
|
|
|
|
|
|
idx = key->conf.keyidx;
|
|
|
|
key->local = sdata->local;
|
|
|
|
key->sdata = sdata;
|
|
|
|
key->sta = sta;
|
|
|
|
|
2007-08-28 17:01:55 -04:00
|
|
|
if (sta) {
|
|
|
|
/*
|
|
|
|
* some hardware cannot handle TKIP with QoS, so
|
|
|
|
* we indicate whether QoS could be in use.
|
|
|
|
*/
|
|
|
|
if (sta->flags & WLAN_STA_WME)
|
|
|
|
key->conf.flags |= IEEE80211_KEY_FLAG_WMM_STA;
|
|
|
|
} else {
|
2007-12-18 19:31:27 -05:00
|
|
|
if (sdata->vif.type == IEEE80211_IF_TYPE_STA) {
|
2007-08-28 17:01:55 -04:00
|
|
|
struct sta_info *ap;
|
|
|
|
|
2008-04-08 11:56:52 -04:00
|
|
|
/*
|
|
|
|
* We're getting a sta pointer in,
|
|
|
|
* so must be under RCU read lock.
|
|
|
|
*/
|
2008-02-25 10:27:46 -05:00
|
|
|
|
2007-08-28 17:01:55 -04:00
|
|
|
/* same here, the AP could be using QoS */
|
|
|
|
ap = sta_info_get(key->local, key->sdata->u.sta.bssid);
|
|
|
|
if (ap) {
|
|
|
|
if (ap->flags & WLAN_STA_WME)
|
|
|
|
key->conf.flags |=
|
|
|
|
IEEE80211_KEY_FLAG_WMM_STA;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-04-08 11:56:52 -04:00
|
|
|
spin_lock_irqsave(&sdata->local->sta_lock, flags);
|
|
|
|
|
[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 11:10:24 -04:00
|
|
|
if (sta)
|
2008-02-25 10:27:45 -05:00
|
|
|
old_key = sta->key;
|
[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 11:10:24 -04:00
|
|
|
else
|
2008-02-25 10:27:45 -05:00
|
|
|
old_key = sdata->keys[idx];
|
|
|
|
|
|
|
|
__ieee80211_key_replace(sdata, sta, old_key, key);
|
[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 11:10:24 -04:00
|
|
|
|
2008-04-08 11:56:52 -04:00
|
|
|
spin_unlock_irqrestore(&sdata->local->sta_lock, flags);
|
|
|
|
|
|
|
|
/* free old key later */
|
|
|
|
add_todo(old_key, KEY_FLAG_TODO_DELETE);
|
2008-02-25 10:27:45 -05:00
|
|
|
|
2008-04-08 11:56:52 -04:00
|
|
|
add_todo(key, KEY_FLAG_TODO_ADD_DEBUGFS);
|
2008-02-27 07:39:00 -05:00
|
|
|
if (netif_running(sdata->dev))
|
2008-04-08 11:56:52 -04:00
|
|
|
add_todo(key, KEY_FLAG_TODO_HWACCEL);
|
2007-07-27 09:43:23 -04:00
|
|
|
}
|
|
|
|
|
2007-08-28 17:01:54 -04:00
|
|
|
void ieee80211_key_free(struct ieee80211_key *key)
|
2007-07-27 09:43:23 -04:00
|
|
|
{
|
2008-04-08 11:56:52 -04:00
|
|
|
unsigned long flags;
|
2008-02-25 10:27:45 -05:00
|
|
|
|
2007-08-28 17:01:54 -04:00
|
|
|
if (!key)
|
|
|
|
return;
|
2007-07-27 09:43:23 -04:00
|
|
|
|
2008-04-08 11:56:52 -04:00
|
|
|
/*
|
|
|
|
* Replace key with nothingness if it was ever used.
|
|
|
|
*/
|
2008-02-25 10:27:45 -05:00
|
|
|
if (key->sdata) {
|
2008-04-08 11:56:52 -04:00
|
|
|
spin_lock_irqsave(&key->sdata->local->sta_lock, flags);
|
|
|
|
__ieee80211_key_replace(key->sdata, key->sta,
|
|
|
|
key, NULL);
|
|
|
|
spin_unlock_irqrestore(&key->sdata->local->sta_lock, flags);
|
|
|
|
}
|
2007-08-28 17:01:55 -04:00
|
|
|
|
2008-04-08 11:56:52 -04:00
|
|
|
add_todo(key, KEY_FLAG_TODO_DELETE);
|
|
|
|
}
|
[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 11:10:24 -04:00
|
|
|
|
2008-04-08 11:56:52 -04:00
|
|
|
void ieee80211_enable_keys(struct ieee80211_sub_if_data *sdata)
|
|
|
|
{
|
|
|
|
struct ieee80211_key *key;
|
[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 11:10:24 -04:00
|
|
|
|
2008-04-08 11:56:52 -04:00
|
|
|
might_sleep();
|
2007-08-28 17:01:55 -04:00
|
|
|
|
2008-04-08 11:56:52 -04:00
|
|
|
if (WARN_ON(!netif_running(sdata->dev)))
|
|
|
|
return;
|
|
|
|
|
|
|
|
ieee80211_key_lock();
|
|
|
|
|
|
|
|
list_for_each_entry(key, &sdata->key_list, list)
|
|
|
|
ieee80211_key_enable_hw_accel(key);
|
|
|
|
|
|
|
|
ieee80211_key_unlock();
|
2007-07-27 09:43:23 -04:00
|
|
|
}
|
2007-08-28 17:01:55 -04:00
|
|
|
|
2008-04-08 11:56:52 -04:00
|
|
|
void ieee80211_disable_keys(struct ieee80211_sub_if_data *sdata)
|
2007-08-28 17:01:55 -04:00
|
|
|
{
|
2008-04-08 11:56:52 -04:00
|
|
|
struct ieee80211_key *key;
|
2007-08-28 17:01:55 -04:00
|
|
|
|
2008-04-08 11:56:52 -04:00
|
|
|
might_sleep();
|
2007-08-28 17:01:55 -04:00
|
|
|
|
2008-04-08 11:56:52 -04:00
|
|
|
ieee80211_key_lock();
|
2007-08-28 17:01:55 -04:00
|
|
|
|
2008-04-08 11:56:52 -04:00
|
|
|
list_for_each_entry(key, &sdata->key_list, list)
|
|
|
|
ieee80211_key_disable_hw_accel(key);
|
2007-08-28 17:01:55 -04:00
|
|
|
|
2008-04-08 11:56:52 -04:00
|
|
|
ieee80211_key_unlock();
|
2007-08-28 17:01:55 -04:00
|
|
|
}
|
|
|
|
|
2008-04-08 11:56:52 -04:00
|
|
|
static void __ieee80211_key_free(struct ieee80211_key *key)
|
2007-08-28 17:01:55 -04:00
|
|
|
{
|
2008-04-08 11:56:52 -04:00
|
|
|
if (!key)
|
|
|
|
return;
|
2008-02-25 10:27:45 -05:00
|
|
|
|
2008-04-08 11:56:52 -04:00
|
|
|
ieee80211_key_disable_hw_accel(key);
|
2007-08-28 17:01:55 -04:00
|
|
|
|
2008-04-08 11:56:52 -04:00
|
|
|
if (key->conf.alg == ALG_CCMP)
|
|
|
|
ieee80211_aes_key_free(key->u.ccmp.tfm);
|
|
|
|
ieee80211_debugfs_key_remove(key);
|
|
|
|
|
|
|
|
kfree(key);
|
2007-08-28 17:01:55 -04:00
|
|
|
}
|
|
|
|
|
2008-04-08 11:56:52 -04:00
|
|
|
static void __ieee80211_key_todo(void)
|
2007-08-28 17:01:55 -04:00
|
|
|
{
|
|
|
|
struct ieee80211_key *key;
|
2008-04-08 11:56:52 -04:00
|
|
|
bool work_done;
|
|
|
|
u32 todoflags;
|
2007-08-28 17:01:55 -04:00
|
|
|
|
2008-04-08 11:56:52 -04:00
|
|
|
/*
|
|
|
|
* NB: sta_info_destroy relies on this!
|
|
|
|
*/
|
|
|
|
synchronize_rcu();
|
|
|
|
|
|
|
|
spin_lock(&todo_lock);
|
|
|
|
while (!list_empty(&todo_list)) {
|
|
|
|
key = list_first_entry(&todo_list, struct ieee80211_key, todo);
|
|
|
|
list_del_init(&key->todo);
|
|
|
|
todoflags = key->flags & (KEY_FLAG_TODO_ADD_DEBUGFS |
|
|
|
|
KEY_FLAG_TODO_DEFKEY |
|
|
|
|
KEY_FLAG_TODO_HWACCEL |
|
|
|
|
KEY_FLAG_TODO_DELETE);
|
|
|
|
key->flags &= ~todoflags;
|
|
|
|
spin_unlock(&todo_lock);
|
|
|
|
|
|
|
|
work_done = false;
|
|
|
|
|
|
|
|
if (todoflags & KEY_FLAG_TODO_ADD_DEBUGFS) {
|
|
|
|
ieee80211_debugfs_key_add(key);
|
|
|
|
work_done = true;
|
|
|
|
}
|
|
|
|
if (todoflags & KEY_FLAG_TODO_DEFKEY) {
|
|
|
|
ieee80211_debugfs_key_remove_default(key->sdata);
|
|
|
|
ieee80211_debugfs_key_add_default(key->sdata);
|
|
|
|
work_done = true;
|
|
|
|
}
|
|
|
|
if (todoflags & KEY_FLAG_TODO_HWACCEL) {
|
|
|
|
ieee80211_key_enable_hw_accel(key);
|
|
|
|
work_done = true;
|
|
|
|
}
|
|
|
|
if (todoflags & KEY_FLAG_TODO_DELETE) {
|
|
|
|
__ieee80211_key_free(key);
|
|
|
|
work_done = true;
|
|
|
|
}
|
2008-02-25 10:27:45 -05:00
|
|
|
|
2008-04-08 11:56:52 -04:00
|
|
|
WARN_ON(!work_done);
|
2007-08-28 17:01:55 -04:00
|
|
|
|
2008-04-08 11:56:52 -04:00
|
|
|
spin_lock(&todo_lock);
|
|
|
|
}
|
|
|
|
spin_unlock(&todo_lock);
|
2007-08-28 17:01:55 -04:00
|
|
|
}
|
|
|
|
|
2008-04-08 11:56:52 -04:00
|
|
|
void ieee80211_key_todo(void)
|
2007-08-28 17:01:55 -04:00
|
|
|
{
|
2008-04-08 11:56:52 -04:00
|
|
|
ieee80211_key_lock();
|
|
|
|
__ieee80211_key_todo();
|
|
|
|
ieee80211_key_unlock();
|
|
|
|
}
|
2007-08-28 17:01:55 -04:00
|
|
|
|
2008-04-08 11:56:52 -04:00
|
|
|
void ieee80211_free_keys(struct ieee80211_sub_if_data *sdata)
|
|
|
|
{
|
|
|
|
struct ieee80211_key *key, *tmp;
|
|
|
|
LIST_HEAD(tmp_list);
|
2008-02-25 10:27:45 -05:00
|
|
|
|
2008-04-08 11:56:52 -04:00
|
|
|
ieee80211_key_lock();
|
|
|
|
|
|
|
|
ieee80211_debugfs_key_remove_default(sdata);
|
|
|
|
|
|
|
|
list_for_each_entry_safe(key, tmp, &sdata->key_list, list)
|
|
|
|
ieee80211_key_free(key);
|
|
|
|
|
|
|
|
__ieee80211_key_todo();
|
|
|
|
|
|
|
|
ieee80211_key_unlock();
|
2007-08-28 17:01:55 -04:00
|
|
|
}
|