| Message ID | 20190629195015.19680-4-alexander@wetzel-home.de (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Luca Coelho |
| Headers | show |
| Series | [1/4] mac80211_hwsim: Extended Key ID API update | expand |
On Sat, 2019-06-29 at 21:50 +0200, Alexander Wetzel wrote: > All iwlwifi cards are able to handle multiple keyids per STA and are > therefore fully compatible with the Extended Key ID implementation > provided by mac80211. > > Allow Extended Key ID to be used for all mvm and dvm cards. > > Signed-off-by: Alexander Wetzel <alexander@wetzel-home.de> > --- > > This is basically the v2 patch of https://patchwork.kernel.org/patch/10931879/ > which Luca still has in his review queue. It just uses the new proposed > simplified Extended Key ID API from this patch series instead. > > Merging (parts) of this series will of course break the older patch > still queued to Luca, so this may need some coordination. Thanks for your patch! I've dropped the old version and will wait until Johannes merges the mac80211 part (and it reaches wireless-drivers- next), so I can apply this. -- Cheers, Luca.
> All iwlwifi cards are able to handle multiple keyids per STA and are > therefore fully compatible with the Extended Key ID implementation > provided by mac80211. I just tried Extended Key ID with a AX200 card and it really looks like it's incompatible:-( The card is starting to use the PTK key immediately after installation, encrypting EAPOL #3 with the new (still Rx only!) key. Digging around in the driver code it looks like we do not even pass the key information any longer to the card: iwl_mvm_set_tx_params() is bypassing iwl_mvm_set_tx_cmd_crypto() completely when we use the "new tx API". So all cards setting "use_tfh" to true are now incompatible. Therefore it looks like that all cards starting with the 22000 series can't be used with Extended Key ID any longer. Is there a way to hand over the key information within the new API or is the way forward to block Extended Key ID when the "new tx API" is being used? The card is fine with using keyid 1 for unicast keys. But it looks like it assumes that a new key install also tells it to use the new key immediately... Still digging around but pretty sure that's happening now. Alexander
On Sat, 2019-08-17 at 10:31 +0200, Alexander Wetzel wrote: > > All iwlwifi cards are able to handle multiple keyids per STA and are > > therefore fully compatible with the Extended Key ID implementation > > provided by mac80211. > > I just tried Extended Key ID with a AX200 card and it really looks like > it's incompatible:-( Hmm. > The card is starting to use the PTK key immediately after installation, > encrypting EAPOL #3 with the new (still Rx only!) key. Right. This wasn't considered, I guess. > Digging around in the driver code it looks like we do not even pass the > key information any longer to the card: iwl_mvm_set_tx_params() is > bypassing iwl_mvm_set_tx_cmd_crypto() completely when we use the "new tx > API". So all cards setting "use_tfh" to true are now incompatible. > > Therefore it looks like that all cards starting with the 22000 series > can't be used with Extended Key ID any longer. > > Is there a way to hand over the key information within the new API or is > the way forward to block Extended Key ID when the "new tx API" is being > used? Not right now, but I think it could be fixed. > The card is fine with using keyid 1 for unicast keys. But it looks like > it assumes that a new key install also tells it to use the new key > immediately... Still digging around but pretty sure that's happening now. Right. For now I guess we have to disable it with the new TX API (which is really what it depends on), we can try to fix the firmware later. johannes
Am 19.08.19 um 11:43 schrieb Johannes Berg: > On Sat, 2019-08-17 at 10:31 +0200, Alexander Wetzel wrote: >>> All iwlwifi cards are able to handle multiple keyids per STA and are >>> therefore fully compatible with the Extended Key ID implementation >>> provided by mac80211. >> >> I just tried Extended Key ID with a AX200 card and it really looks like >> it's incompatible:-( > > Hmm. > >> The card is starting to use the PTK key immediately after installation, >> encrypting EAPOL #3 with the new (still Rx only!) key. > > Right. This wasn't considered, I guess. > >> Digging around in the driver code it looks like we do not even pass the >> key information any longer to the card: iwl_mvm_set_tx_params() is >> bypassing iwl_mvm_set_tx_cmd_crypto() completely when we use the "new tx >> API". So all cards setting "use_tfh" to true are now incompatible. >> >> Therefore it looks like that all cards starting with the 22000 series >> can't be used with Extended Key ID any longer. >> >> Is there a way to hand over the key information within the new API or is >> the way forward to block Extended Key ID when the "new tx API" is being >> used? > > Not right now, but I think it could be fixed. That would be great! We may also get away by adding only means to pass the keyid of the MPDU (zero or one) to the HW. That could be done quite simple, I think: We could add two new flags, e.g. IWL_TX_FLAGS_ENCRYPT_ID_0 and IWL_TX_FLAGS_ENCRYPT_ID_1 to avoid the need to change the structures iwl_tx_cmd_gen2 and iwl_tx_cmd_gen3. When the firmware would check and use the key referenced by the STA + flag-id prior to the "last installed" key that should be sufficient. By still using the last installed key without any of the new flags set we also would remain backward compatible. If you have any experimental firmware to test I'm happy to do so:-) Till then I'm back using older iwlwifi cards. > >> The card is fine with using keyid 1 for unicast keys. But it looks like >> it assumes that a new key install also tells it to use the new key >> immediately... Still digging around but pretty sure that's happening now. > > Right. > > For now I guess we have to disable it with the new TX API (which is > really what it depends on), we can try to fix the firmware later. Ok. I'll update the iwlwifi Extended key ID support patch accordingly. Alexander
On Mon, 2019-08-19 at 17:52 +0200, Alexander Wetzel wrote: > We may also get away by adding only means to pass the keyid of the MPDU > (zero or one) to the HW. That could be done quite simple, I think: > > We could add two new flags, e.g. IWL_TX_FLAGS_ENCRYPT_ID_0 and > IWL_TX_FLAGS_ENCRYPT_ID_1 to avoid the need to change the structures > iwl_tx_cmd_gen2 and iwl_tx_cmd_gen3. > When the firmware would check and use the key referenced by the STA + > flag-id prior to the "last installed" key that should be sufficient. > By still using the last installed key without any of the new flags set > we also would remain backward compatible. > > If you have any experimental firmware to test I'm happy to do so:-) > Till then I'm back using older iwlwifi cards. I'm not convinced that we can change the TX API at all, I suspect we have to go detect it as we saw in the other patch. If we do actually have the ability to change the TX API it might be simpler overall, but anyway, I'd have to go look at how this is all implemented before I comment further. Doesn't seem like an intractable problem, the only question is if we get to spend time on it :) johannes
Am 19.08.19 um 22:23 schrieb Johannes Berg: > On Mon, 2019-08-19 at 17:52 +0200, Alexander Wetzel wrote: > >> We may also get away by adding only means to pass the keyid of the MPDU >> (zero or one) to the HW. That could be done quite simple, I think: >> >> We could add two new flags, e.g. IWL_TX_FLAGS_ENCRYPT_ID_0 and >> IWL_TX_FLAGS_ENCRYPT_ID_1 to avoid the need to change the structures >> iwl_tx_cmd_gen2 and iwl_tx_cmd_gen3. >> When the firmware would check and use the key referenced by the STA + >> flag-id prior to the "last installed" key that should be sufficient. >> By still using the last installed key without any of the new flags set >> we also would remain backward compatible. >> >> If you have any experimental firmware to test I'm happy to do so:-) >> Till then I'm back using older iwlwifi cards. > > I'm not convinced that we can change the TX API at all, I suspect we > have to go detect it as we saw in the other patch. If we do actually > have the ability to change the TX API it might be simpler overall, but > anyway, I'd have to go look at how this is all implemented before I > comment further. Doesn't seem like an intractable problem, the only > question is if we get to spend time on it :) You are thinking about keeping the tx API untouched and modify the key install logic? Just prevent the firmware to activate a key for Tx when it's installed and notify the firmware by some means when the key can be used for Tx and then switch everything to the new key? I guess there is no practical way I can get access to the firmware code, correct? For me it sounds harder than the optional flag extension I had in mind for the new tx API. After all one of the existing flags can already suppress the encryption. Checking for the presence of two optional flags and use these to select a different key sounded not very hard. But then I literally know nothing about that and if the card/firmware has some fundamental issue handling two unicast keys the picture changes of course... So let's wait and see what you can turn up. Till then we have more than enough other cards supporting Extended Key ID:-) Alexander
Hi, > You are thinking about keeping the tx API untouched and modify the key > install logic? > Just prevent the firmware to activate a key for Tx when it's installed > and notify the firmware by some means when the key can be used for Tx > and then switch everything to the new key? Something like that, yes. > I guess there is no practical way I can get access to the firmware code, > correct? There isn't, yeah. > For me it sounds harder than the optional flag extension I had > in mind for the new tx API. Much more of the TX path is actually wired into the hardware, rather than being software. I'm not sure how much of this (key selection) really is though. > So let's wait and see what you can turn up. Till then we have more than > enough other cards supporting Extended Key ID:-) Yeah. I'll take a look, but I can't promise right now to work on it high priority. johannes
diff --git a/drivers/net/wireless/intel/iwlwifi/dvm/mac80211.c b/drivers/net/wireless/intel/iwlwifi/dvm/mac80211.c index 6c170636110a..ac88c19f4f18 100644 --- a/drivers/net/wireless/intel/iwlwifi/dvm/mac80211.c +++ b/drivers/net/wireless/intel/iwlwifi/dvm/mac80211.c @@ -200,6 +200,7 @@ int iwlagn_mac_setup_register(struct iwl_priv *priv, iwl_leds_init(priv); wiphy_ext_feature_set(hw->wiphy, NL80211_EXT_FEATURE_CQM_RSSI_LIST); + wiphy_ext_feature_set(hw->wiphy, NL80211_EXT_FEATURE_EXT_KEY_ID); ret = ieee80211_register_hw(priv->hw); if (ret) { diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c index fdbabca0280e..c752fe6970e3 100644 --- a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c +++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c @@ -599,6 +599,7 @@ int iwl_mvm_mac_setup_register(struct iwl_mvm *mvm) hw->wiphy->flags |= WIPHY_FLAG_IBSS_RSN; wiphy_ext_feature_set(hw->wiphy, NL80211_EXT_FEATURE_VHT_IBSS); + wiphy_ext_feature_set(hw->wiphy, NL80211_EXT_FEATURE_EXT_KEY_ID); hw->wiphy->features |= NL80211_FEATURE_HT_IBSS; hw->wiphy->regulatory_flags |= REGULATORY_ENABLE_RELAX_NO_IR;
All iwlwifi cards are able to handle multiple keyids per STA and are therefore fully compatible with the Extended Key ID implementation provided by mac80211. Allow Extended Key ID to be used for all mvm and dvm cards. Signed-off-by: Alexander Wetzel <alexander@wetzel-home.de> --- This is basically the v2 patch of https://patchwork.kernel.org/patch/10931879/ which Luca still has in his review queue. It just uses the new proposed simplified Extended Key ID API from this patch series instead. Merging (parts) of this series will of course break the older patch still queued to Luca, so this may need some coordination. drivers/net/wireless/intel/iwlwifi/dvm/mac80211.c | 1 + drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 1 + 2 files changed, 2 insertions(+)