2007-07-27 15:43:23 +02:00
|
|
|
/*
|
|
|
|
* Copyright 2002-2005, Instant802 Networks, Inc.
|
|
|
|
* Copyright 2005-2006, Devicescape Software, Inc.
|
|
|
|
* Copyright 2006-2007 Jiri Benc <jbenc@suse.cz>
|
2007-08-28 23:01:55 +02:00
|
|
|
* Copyright 2007 Johannes Berg <johannes@sipsolutions.net>
|
2007-07-27 15:43:23 +02: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 23:01:55 +02: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 17:10:24 +02:00
|
|
|
#include <linux/rcupdate.h>
|
2007-07-27 15:43:23 +02:00
|
|
|
#include <net/mac80211.h>
|
|
|
|
#include "ieee80211_i.h"
|
|
|
|
#include "debugfs_key.h"
|
|
|
|
#include "aes_ccm.h"
|
|
|
|
|
2007-08-28 23:01:55 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Key handling basics
|
|
|
|
*
|
|
|
|
* 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.
|
|
|
|
*
|
|
|
|
* All operations here are called under RTNL so no extra locking is
|
|
|
|
* required.
|
|
|
|
*/
|
|
|
|
|
|
|
|
static const u8 bcast_addr[ETH_ALEN] = { 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF };
|
|
|
|
static const u8 zero_addr[ETH_ALEN];
|
|
|
|
|
|
|
|
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-19 01:31:27 +01:00
|
|
|
(key->sdata->vif.type == IEEE80211_IF_TYPE_AP ||
|
|
|
|
key->sdata->vif.type == IEEE80211_IF_TYPE_VLAN))
|
2007-08-28 23:01:55 +02: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-04 02:59:30 +02:00
|
|
|
DECLARE_MAC_BUF(mac);
|
2007-08-28 23:01:55 +02: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);
|
|
|
|
|
|
|
|
if (!ret)
|
|
|
|
key->flags |= KEY_FLAG_UPLOADED_TO_HARDWARE;
|
|
|
|
|
|
|
|
if (ret && ret != -ENOSPC && ret != -EOPNOTSUPP)
|
|
|
|
printk(KERN_ERR "mac80211-%s: failed to set key "
|
2007-10-04 02:59:30 +02:00
|
|
|
"(%d, %s) to hardware (%d)\n",
|
2007-08-28 23:01:55 +02:00
|
|
|
wiphy_name(key->local->hw.wiphy),
|
2007-10-04 02:59:30 +02:00
|
|
|
key->conf.keyidx, print_mac(mac, addr), ret);
|
2007-08-28 23:01:55 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
static void ieee80211_key_disable_hw_accel(struct ieee80211_key *key)
|
|
|
|
{
|
|
|
|
const u8 *addr;
|
|
|
|
int ret;
|
2007-10-04 02:59:30 +02:00
|
|
|
DECLARE_MAC_BUF(mac);
|
2007-08-28 23:01:55 +02:00
|
|
|
|
|
|
|
if (!key->local->ops->set_key)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (!(key->flags & KEY_FLAG_UPLOADED_TO_HARDWARE))
|
|
|
|
return;
|
|
|
|
|
|
|
|
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-04 02:59:30 +02:00
|
|
|
"(%d, %s) from hardware (%d)\n",
|
2007-08-28 23:01:55 +02:00
|
|
|
wiphy_name(key->local->hw.wiphy),
|
2007-10-04 02:59:30 +02:00
|
|
|
key->conf.keyidx, print_mac(mac, addr), ret);
|
2007-08-28 23:01:55 +02:00
|
|
|
|
|
|
|
key->flags &= ~KEY_FLAG_UPLOADED_TO_HARDWARE;
|
|
|
|
}
|
|
|
|
|
2007-07-27 15:43:23 +02:00
|
|
|
struct ieee80211_key *ieee80211_key_alloc(struct ieee80211_sub_if_data *sdata,
|
2007-08-28 23:01:55 +02:00
|
|
|
struct sta_info *sta,
|
2007-09-18 23:29:21 +02:00
|
|
|
enum ieee80211_key_alg alg,
|
2007-08-28 23:01:55 +02:00
|
|
|
int idx,
|
|
|
|
size_t key_len,
|
|
|
|
const u8 *key_data)
|
2007-07-27 15:43:23 +02: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 17:10:24 +02:00
|
|
|
BUG_ON(idx < 0 || idx >= NUM_DEFAULT_KEYS);
|
2007-08-28 23:01:55 +02:00
|
|
|
|
|
|
|
key = kzalloc(sizeof(struct ieee80211_key) + key_len, GFP_KERNEL);
|
2007-07-27 15:43:23 +02:00
|
|
|
if (!key)
|
|
|
|
return NULL;
|
2007-08-28 23:01:55 +02: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);
|
|
|
|
|
|
|
|
key->local = sdata->local;
|
|
|
|
key->sdata = sdata;
|
|
|
|
key->sta = sta;
|
|
|
|
|
|
|
|
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) {
|
|
|
|
ieee80211_key_free(key);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
ieee80211_debugfs_key_add(key->local, 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 17:10:24 +02:00
|
|
|
/* remove key first */
|
|
|
|
if (sta)
|
|
|
|
ieee80211_key_free(sta->key);
|
|
|
|
else
|
|
|
|
ieee80211_key_free(sdata->keys[idx]);
|
|
|
|
|
2007-08-28 23:01:55 +02:00
|
|
|
if (sta) {
|
|
|
|
ieee80211_debugfs_key_sta_link(key, sta);
|
[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 17:10:24 +02:00
|
|
|
|
2007-08-28 23:01:55 +02:00
|
|
|
/*
|
|
|
|
* 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-19 01:31:27 +01:00
|
|
|
if (sdata->vif.type == IEEE80211_IF_TYPE_STA) {
|
2007-08-28 23:01:55 +02:00
|
|
|
struct sta_info *ap;
|
|
|
|
|
|
|
|
/* 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;
|
|
|
|
sta_info_put(ap);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
[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 17:10:24 +02:00
|
|
|
/* enable hwaccel if appropriate */
|
2007-08-28 23:01:55 +02:00
|
|
|
if (netif_running(key->sdata->dev))
|
|
|
|
ieee80211_key_enable_hw_accel(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 17:10:24 +02:00
|
|
|
if (sta)
|
|
|
|
rcu_assign_pointer(sta->key, key);
|
|
|
|
else
|
|
|
|
rcu_assign_pointer(sdata->keys[idx], key);
|
|
|
|
|
|
|
|
list_add(&key->list, &sdata->key_list);
|
|
|
|
|
2007-07-27 15:43:23 +02:00
|
|
|
return key;
|
|
|
|
}
|
|
|
|
|
2007-08-28 23:01:54 +02:00
|
|
|
void ieee80211_key_free(struct ieee80211_key *key)
|
2007-07-27 15:43:23 +02:00
|
|
|
{
|
2007-08-28 23:01:54 +02:00
|
|
|
if (!key)
|
|
|
|
return;
|
2007-07-27 15:43:23 +02:00
|
|
|
|
2007-08-28 23:01:55 +02:00
|
|
|
if (key->sta) {
|
[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 17:10:24 +02:00
|
|
|
rcu_assign_pointer(key->sta->key, NULL);
|
2007-08-28 23:01:55 +02:00
|
|
|
} else {
|
|
|
|
if (key->sdata->default_key == key)
|
|
|
|
ieee80211_set_default_key(key->sdata, -1);
|
|
|
|
if (key->conf.keyidx >= 0 &&
|
|
|
|
key->conf.keyidx < NUM_DEFAULT_KEYS)
|
[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 17:10:24 +02:00
|
|
|
rcu_assign_pointer(key->sdata->keys[key->conf.keyidx],
|
|
|
|
NULL);
|
2007-08-28 23:01:55 +02:00
|
|
|
else
|
|
|
|
WARN_ON(1);
|
|
|
|
}
|
|
|
|
|
[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 17:10:24 +02:00
|
|
|
/* wait for all key users to complete */
|
|
|
|
synchronize_rcu();
|
|
|
|
|
|
|
|
/* remove from hwaccel if appropriate */
|
|
|
|
ieee80211_key_disable_hw_accel(key);
|
|
|
|
|
2007-08-28 23:01:54 +02:00
|
|
|
if (key->conf.alg == ALG_CCMP)
|
2007-07-27 15:43:23 +02:00
|
|
|
ieee80211_aes_key_free(key->u.ccmp.tfm);
|
|
|
|
ieee80211_debugfs_key_remove(key);
|
2007-08-28 23:01:55 +02:00
|
|
|
|
|
|
|
list_del(&key->list);
|
|
|
|
|
2007-07-27 15:43:23 +02:00
|
|
|
kfree(key);
|
|
|
|
}
|
2007-08-28 23:01:55 +02:00
|
|
|
|
|
|
|
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];
|
|
|
|
|
|
|
|
if (sdata->default_key != key) {
|
|
|
|
ieee80211_debugfs_key_remove_default(sdata);
|
|
|
|
|
[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 17:10:24 +02:00
|
|
|
rcu_assign_pointer(sdata->default_key, key);
|
2007-08-28 23:01:55 +02:00
|
|
|
|
|
|
|
if (sdata->default_key)
|
|
|
|
ieee80211_debugfs_key_add_default(sdata);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void ieee80211_free_keys(struct ieee80211_sub_if_data *sdata)
|
|
|
|
{
|
|
|
|
struct ieee80211_key *key, *tmp;
|
|
|
|
|
|
|
|
list_for_each_entry_safe(key, tmp, &sdata->key_list, list)
|
|
|
|
ieee80211_key_free(key);
|
|
|
|
}
|
|
|
|
|
|
|
|
void ieee80211_enable_keys(struct ieee80211_sub_if_data *sdata)
|
|
|
|
{
|
|
|
|
struct ieee80211_key *key;
|
|
|
|
|
|
|
|
WARN_ON(!netif_running(sdata->dev));
|
|
|
|
if (!netif_running(sdata->dev))
|
|
|
|
return;
|
|
|
|
|
|
|
|
list_for_each_entry(key, &sdata->key_list, list)
|
|
|
|
ieee80211_key_enable_hw_accel(key);
|
|
|
|
}
|
|
|
|
|
|
|
|
void ieee80211_disable_keys(struct ieee80211_sub_if_data *sdata)
|
|
|
|
{
|
|
|
|
struct ieee80211_key *key;
|
|
|
|
|
|
|
|
list_for_each_entry(key, &sdata->key_list, list)
|
|
|
|
ieee80211_key_disable_hw_accel(key);
|
|
|
|
}
|