Message ID | 20190210210620.31181-10-alexander@wetzel-home.de (mailing list archive) |
---|---|
State | RFC |
Delegated to: | Johannes Berg |
Headers | show |
Series | Draft for Extended Key ID support | expand |
Alexander Wetzel <alexander@wetzel-home.de> writes: > Extend the shared ath key cache code to support Extended Key ID. > > The key cache code has to accept unicast keys to use key idx 1 and allow > drivers to enable/disable hardware Rx decryption for a key independent > from Tx. > > Signed-off-by: Alexander Wetzel <alexander@wetzel-home.de> > --- > > I know this is the wrong audience to discuss ath drivers. I think this is the right forum. Do note that somewhere in this patch (in the cover letter) you mentioned "all ath drivers" but AFAICS this patch only changes functionality for ath5k, ath9k and ath9k_htc. All the rest like wil6210, ath6kl and ath10k are unaffected.
> >> Extend the shared ath key cache code to support Extended Key ID. >> >> The key cache code has to accept unicast keys to use key idx 1 and allow >> drivers to enable/disable hardware Rx decryption for a key independent >> from Tx. >> >> Signed-off-by: Alexander Wetzel <alexander@wetzel-home.de> >> --- >> >> I know this is the wrong audience to discuss ath drivers. > > I think this is the right forum. Do note that somewhere in this patch You are of course right. I mixed that up somehow. We can of course also discuss the ath patches any time :-) My initial plan was, to get the nl80211/mac80211 API finalized and then get them reviewed together with another planned fix after some more polishing. At this stage they are just a POC and not ready for merge. They work with ath9k in AP (vlan) mode and I believe managed mode should either work or need some trivial fix only. (There even seems to be a chance that managed mode could allow the usage of the NATIVE Extended Key ID mode, but so far I could not tested that.) > (in the cover letter) you mentioned "all ath drivers" but AFAICS this > patch only changes functionality for ath5k, ath9k and ath9k_htc. All the > rest like wil6210, ath6kl and ath10k are unaffected. > You are right, I should have used "shared ath key cache code" in the Cover Letter, as in the patch itself. This is not (yet) an attempt to implement Extended Key ID for anything else than ath9k AP mode. So any driver not using ath_key_config() won't be affected at all. Now I believe it's possible for all Atheros drivers but the ath10k to get support. As long as a card can work with SW crypto we only need a way to disable Rx HW crypto for a running key without impact for ongoing Tx. But the initial results when trying my hand at ath10k are strongly indicating the best we can hope there is SW encryption only with CT firmware... or maybe a firmware update. While the API itself is perfectly able to handle NATIVE mode the keyid is not handled correctly. Installing a second key switches TX to the new key and overwrites the keyid in the MPDU mac80211 prepared. (I could not even get the card to properly make an RX/TX key to an TX only key, that caused clear text packets when changing the key and it looks like that SW crypto is only possible - with nonfree CT - when not using HW crypto for TX at all. With those limitations I shelved any plans for ath10k.) One of my next planned steps is now to either get another ath9k card or get another driver working in AP mode to test ath9k also in managed mode. Of course I also have to get sniffing working properly, all cards tried so far have issues and it also looks like I have to update wireshark for serious testing. So I guess driver support will still take some time and efforts when we got the generic issues sorted out. I can also try my hand at porting the other Atheros drives, but without someone being able to confirm it works I'm not planning that at the moment. Alexander
diff --git a/drivers/net/wireless/ath/ath.h b/drivers/net/wireless/ath/ath.h index cc45ccfea5af..465629448fdf 100644 --- a/drivers/net/wireless/ath/ath.h +++ b/drivers/net/wireless/ath/ath.h @@ -202,8 +202,13 @@ void ath_key_delete(struct ath_common *common, struct ieee80211_key_conf *key); int ath_key_config(struct ath_common *common, struct ieee80211_vif *vif, struct ieee80211_sta *sta, - struct ieee80211_key_conf *key); + struct ieee80211_key_conf *key, + bool rx_accel); bool ath_hw_keyreset(struct ath_common *common, u16 entry); +bool ath_hw_rx_crypt(struct ath_common *common, + struct ieee80211_key_conf *key, + struct ieee80211_sta *sta, + bool rx_accel); void ath_hw_cycle_counters_update(struct ath_common *common); int32_t ath_hw_get_listen_time(struct ath_common *common); diff --git a/drivers/net/wireless/ath/key.c b/drivers/net/wireless/ath/key.c index 689fab9acf10..ced1c89102ad 100644 --- a/drivers/net/wireless/ath/key.c +++ b/drivers/net/wireless/ath/key.c @@ -126,6 +126,23 @@ static bool ath_hw_keysetmac(struct ath_common *common, return true; } +bool ath_hw_rx_crypt(struct ath_common *common, + struct ieee80211_key_conf *key, + struct ieee80211_sta *sta, + bool rx_accel) +{ + const u8 *mac = NULL; + + if (!sta || !test_bit(key->hw_key_idx, common->keymap)) + return false; + + if (rx_accel) + mac = sta->addr; + + return ath_hw_keysetmac(common, key->hw_key_idx, mac); +} +EXPORT_SYMBOL(ath_hw_rx_crypt); + static bool ath_hw_set_keycache_entry(struct ath_common *common, u16 entry, const struct ath_keyval *k, const u8 *mac) @@ -473,7 +490,8 @@ static int ath_reserve_key_cache_slot(struct ath_common *common, int ath_key_config(struct ath_common *common, struct ieee80211_vif *vif, struct ieee80211_sta *sta, - struct ieee80211_key_conf *key) + struct ieee80211_key_conf *key, + bool rx_accel) { struct ath_keyval hk; const u8 *mac = NULL; @@ -527,21 +545,28 @@ int ath_key_config(struct ath_common *common, idx = key->keyidx; break; } - } else if (key->keyidx) { + } else if (key->keyidx > 1) { if (WARN_ON(!sta)) return -EOPNOTSUPP; mac = sta->addr; if (vif->type != NL80211_IFTYPE_AP) { - /* Only keyidx 0 should be used with unicast key, but - * allow this for client mode for now. */ + /* Only keyidx 0 and when using Extended Key ID 1 should + * be used with a unicast key. But allow this for client + * mode for now. + */ idx = key->keyidx; } else return -EIO; } else { if (WARN_ON(!sta)) return -EOPNOTSUPP; - mac = sta->addr; + + /* Handle sta Tx only keys like GTK keys for now */ + if (rx_accel) + mac = sta->addr; + else + mac = NULL; idx = ath_reserve_key_cache_slot(common, key->cipher); }
Extend the shared ath key cache code to support Extended Key ID. The key cache code has to accept unicast keys to use key idx 1 and allow drivers to enable/disable hardware Rx decryption for a key independent from Tx. Signed-off-by: Alexander Wetzel <alexander@wetzel-home.de> --- I know this is the wrong audience to discuss ath drivers. It's only included here as an example and POC that the Compatibility Extended Key ID means for drivers. This has so far only got the minimal attention needed to get it working for my AP used for tests. The idea is, to discuss that with the proper audience once we know what mac80211 Extended Key ID support will look like. drivers/net/wireless/ath/ath.h | 7 ++++++- drivers/net/wireless/ath/key.c | 35 +++++++++++++++++++++++++++++----- 2 files changed, 36 insertions(+), 6 deletions(-)