diff mbox series

mac80211: Set CAN_REPLACE_PTK0 for SW crypto only drivers

Message ID 20190424173246.26421-1-alexander@wetzel-home.de (mailing list archive)
State Accepted
Delegated to: Johannes Berg
Headers show
Series mac80211: Set CAN_REPLACE_PTK0 for SW crypto only drivers | expand

Commit Message

Alexander Wetzel April 24, 2019, 5:32 p.m. UTC
Mac80211 SW crypto handles replacing PTK keys correctly.

Don't trigger needless warnings or workarounds when the driver can only
use the known good SW crypto provided by mac80211.

Signed-off-by: Alexander Wetzel <alexander@wetzel-home.de>
---
 net/mac80211/main.c | 7 +++++++
 1 file changed, 7 insertions(+)

Comments

Johannes Berg April 24, 2019, 6:55 p.m. UTC | #1
On Wed, 2019-04-24 at 19:32 +0200, Alexander Wetzel wrote:
> Mac80211 SW crypto handles replacing PTK keys correctly.
> 
> Don't trigger needless warnings or workarounds when the driver can only
> use the known good SW crypto provided by mac80211.
> 
> Signed-off-by: Alexander Wetzel <alexander@wetzel-home.de>
> ---
>  net/mac80211/main.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/net/mac80211/main.c b/net/mac80211/main.c
> index e56650a9838e..2b608044ae23 100644
> --- a/net/mac80211/main.c
> +++ b/net/mac80211/main.c
> @@ -1060,6 +1060,13 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
>  		wiphy_ext_feature_set(local->hw.wiphy,
>  				      NL80211_EXT_FEATURE_EXT_KEY_ID);
>  
> +	/* Mac80211 and therefore all cards only using SW crypto are able to
> +	 * handle PTK rekeys correctly
> +	 */
> +	if (!local->ops->set_key)
> +		wiphy_ext_feature_set(local->hw.wiphy,
> +				      NL80211_EXT_FEATURE_CAN_REPLACE_PTK0);

Now I wonder - shouldn't the same A-MPDU issue apply here? After all, if
you replace the PTK 0 surely you shouldn't use different ones for the
same frame in an A-MPDU?

johannes
Alexander Wetzel April 24, 2019, 8:58 p.m. UTC | #2
Am 24.04.19 um 20:55 schrieb Johannes Berg:
> On Wed, 2019-04-24 at 19:32 +0200, Alexander Wetzel wrote:
>> Mac80211 SW crypto handles replacing PTK keys correctly.
>>
>> Don't trigger needless warnings or workarounds when the driver can only
>> use the known good SW crypto provided by mac80211.
>>
>> Signed-off-by: Alexander Wetzel <alexander@wetzel-home.de>
>> ---
>>   net/mac80211/main.c | 7 +++++++
>>   1 file changed, 7 insertions(+)
>>
>> diff --git a/net/mac80211/main.c b/net/mac80211/main.c
>> index e56650a9838e..2b608044ae23 100644
>> --- a/net/mac80211/main.c
>> +++ b/net/mac80211/main.c
>> @@ -1060,6 +1060,13 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
>>   		wiphy_ext_feature_set(local->hw.wiphy,
>>   				      NL80211_EXT_FEATURE_EXT_KEY_ID);
>>   
>> +	/* Mac80211 and therefore all cards only using SW crypto are able to
>> +	 * handle PTK rekeys correctly
>> +	 */
>> +	if (!local->ops->set_key)
>> +		wiphy_ext_feature_set(local->hw.wiphy,
>> +				      NL80211_EXT_FEATURE_CAN_REPLACE_PTK0);
> 
> Now I wonder - shouldn't the same A-MPDU issue apply here? After all, if
> you replace the PTK 0 surely you shouldn't use different ones for the
> same frame in an A-MPDU?

Not from what I found in IEEE 802.11. It's only forbidden to mix keyIDs, 
not MPDUs using different keys. And without Extended Key ID the keyID 
can only be zero. So from a standard point of view we are ok, no keyID 
mixing possible.

 From a practical point of view cards like mvm cards will for sure 
corrupt MPDUs aggregated in a A-MPDU when different key were used for 
them. But we still don't care:-)

We'll corrupt the MPDU's encoded with either the old or the new key 
anyhow and we don't care which ones. After all the card will only have 
one key active for key ID 0 at any time won't have the second key 
installed at all.

Alexander
Johannes Berg April 24, 2019, 9:01 p.m. UTC | #3
On Wed, 2019-04-24 at 22:58 +0200, Alexander Wetzel wrote:
> 
> > Now I wonder - shouldn't the same A-MPDU issue apply here? After all, if
> > you replace the PTK 0 surely you shouldn't use different ones for the
> > same frame in an A-MPDU?
> 
> Not from what I found in IEEE 802.11. It's only forbidden to mix keyIDs, 
> not MPDUs using different keys. And without Extended Key ID the keyID 
> can only be zero. So from a standard point of view we are ok, no keyID 
> mixing possible.

Yeah, well, the standard probably didn't consider this. From an
implementation POV, having two subframes with different keys will not
really be possible, *especially* if they have the same key ID.

I think this basically was not considered in spec writing.

> From a practical point of view cards like mvm cards will for sure 
> corrupt MPDUs aggregated in a A-MPDU when different key were used for 
> them. But we still don't care:-)
> 
> We'll corrupt the MPDU's encoded with either the old or the new key 
> anyhow and we don't care which ones. After all the card will only have 
> one key active for key ID 0 at any time won't have the second key 
> installed at all.

Yeah, ok, fair point.

johannes
diff mbox series

Patch

diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index e56650a9838e..2b608044ae23 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -1060,6 +1060,13 @@  int ieee80211_register_hw(struct ieee80211_hw *hw)
 		wiphy_ext_feature_set(local->hw.wiphy,
 				      NL80211_EXT_FEATURE_EXT_KEY_ID);
 
+	/* Mac80211 and therefore all cards only using SW crypto are able to
+	 * handle PTK rekeys correctly
+	 */
+	if (!local->ops->set_key)
+		wiphy_ext_feature_set(local->hw.wiphy,
+				      NL80211_EXT_FEATURE_CAN_REPLACE_PTK0);
+
 	/*
 	 * Calculate scan IE length -- we need this to alloc
 	 * memory and to subtract from the driver limit. It