[PATCH] mac80211: Use sw crypto for GTKs on AP VLAN interfaces

[PATCH] mac80211: Use sw crypto for GTKs on AP VLAN interfaces

[Helmut Schaa]

When using AP VLAN interfaces, each VLAN interface should be in its own
broadcast domain. Hostapd achieves this by assigning different GTKs to
different AP VLAN interfaces.

However, mac80211 drivers are not aware of AP VLAN interfaces and as
such mac80211 sends the GTK to the driver in the context of the base AP
mode interface. This causes problems when multiple AP VLAN interfaces
are used since the driver will use the same key slot for the different
GTKs (there's no way for the driver to distinguish the different GTKs
from different AP VLAN interfaces). Thus, only the clients associated
to one AP VLAN interface (the one that was created last) can actually
use broadcast traffic.

Fix this by not programming any GTKs for AP VLAN interfaces into the hw
but fall back to using software crypto. The GTK for the underlying AP
interface is still sent to the driver.

That means, broadcast traffic to and from stations associated to an AP
VLAN interface is encrypted and decrypted in software whereas broadcast
traffic to and from stations associated to the non-VLAN AP interface is
encrypted end decrypted in hardware.

Cc: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
---

This incidentally also fixes the mac8011 oops related to AP VLAN
interfaces I've reported earlier.

If we want to support hardware crypto for broadcast traffic on AP VLAN
interfaces we'd either need to switch to per station GTKs or need to
make drivers aware of VLAN interfaces. Not sure if it's worth it.

At least current rt2x00 devices won't be able to support that due to
the limited amount of available key space.

 net/mac80211/key.c |    9 ++++++++-
 1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/net/mac80211/key.c b/net/mac80211/key.c
index ccd676b..72df1ca 100644
--- a/net/mac80211/key.c
+++ b/net/mac80211/key.c
@@ -84,10 +84,17 @@ static int ieee80211_key_enable_hw_accel(struct ieee80211_key *key)
 		goto out_unsupported;
 
 	sdata = key->sdata;
-	if (sdata->vif.type == NL80211_IFTYPE_AP_VLAN)
+	if (sdata->vif.type == NL80211_IFTYPE_AP_VLAN) {
+		/*
+		 * The driver doesn't know anything about VLAN interfaces.
+		 * Hence, don't send GTKs for VLAN interfaces to the driver.
+		 */
+		if (!(key->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE))
+			goto out_unsupported;
 		sdata = container_of(sdata->bss,
 				     struct ieee80211_sub_if_data,
 				     u.ap);
+	}
 
 	ret = drv_set_key(key->local, SET_KEY, sdata, sta, &key->conf);
 
-- 
1.7.1

Re: [PATCH] mac80211: Use sw crypto for GTKs on AP VLAN interfaces

[Johannes Berg]

On Thu, 2010-11-18 at 16:36 +0100, Helmut Schaa wrote:
> When using AP VLAN interfaces, each VLAN interface should be in its own
> broadcast domain. Hostapd achieves this by assigning different GTKs to
> different AP VLAN interfaces.
> 
> However, mac80211 drivers are not aware of AP VLAN interfaces and as
> such mac80211 sends the GTK to the driver in the context of the base AP
> mode interface. This causes problems when multiple AP VLAN interfaces
> are used since the driver will use the same key slot for the different
> GTKs (there's no way for the driver to distinguish the different GTKs
> from different AP VLAN interfaces). Thus, only the clients associated
> to one AP VLAN interface (the one that was created last) can actually
> use broadcast traffic.
> 
> Fix this by not programming any GTKs for AP VLAN interfaces into the hw
> but fall back to using software crypto. The GTK for the underlying AP
> interface is still sent to the driver.
> 
> That means, broadcast traffic to and from stations associated to an AP
> VLAN interface is encrypted and decrypted in software whereas broadcast
> traffic to and from stations associated to the non-VLAN AP interface is
> encrypted end decrypted in hardware.

Minor nit: bcast traffic from stations is never decrypted by these keys
since stations never send real bcast frames -- just remove the decyrpted
part and "from stations" part :-)

> Cc: Johannes Berg <johannes@sipsolutions.net>
> Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
> ---
> 
> This incidentally also fixes the mac8011 oops related to AP VLAN
> interfaces I've reported earlier.
> 
> If we want to support hardware crypto for broadcast traffic on AP VLAN
> interfaces we'd either need to switch to per station GTKs or need to
> make drivers aware of VLAN interfaces. Not sure if it's worth it.
> 
> At least current rt2x00 devices won't be able to support that due to
> the limited amount of available key space.


Hmm, good point. Jouni, any comments? Lennert maybe?

johannes

>  net/mac80211/key.c |    9 ++++++++-
>  1 files changed, 8 insertions(+), 1 deletions(-)
> 
> diff --git a/net/mac80211/key.c b/net/mac80211/key.c
> index ccd676b..72df1ca 100644
> --- a/net/mac80211/key.c
> +++ b/net/mac80211/key.c
> @@ -84,10 +84,17 @@ static int ieee80211_key_enable_hw_accel(struct ieee80211_key *key)
>  		goto out_unsupported;
>  
>  	sdata = key->sdata;
> -	if (sdata->vif.type == NL80211_IFTYPE_AP_VLAN)
> +	if (sdata->vif.type == NL80211_IFTYPE_AP_VLAN) {
> +		/*
> +		 * The driver doesn't know anything about VLAN interfaces.
> +		 * Hence, don't send GTKs for VLAN interfaces to the driver.
> +		 */
> +		if (!(key->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE))
> +			goto out_unsupported;
>  		sdata = container_of(sdata->bss,
>  				     struct ieee80211_sub_if_data,
>  				     u.ap);
> +	}
>  
>  	ret = drv_set_key(key->local, SET_KEY, sdata, sta, &key->conf);
>  

Re: [PATCH] mac80211: Use sw crypto for GTKs on AP VLAN interfaces

[Jouni Malinen]

On Thu, Nov 18, 2010 at 09:01:39AM -0800, Johannes Berg wrote:
> On Thu, 2010-11-18 at 16:36 +0100, Helmut Schaa wrote:
> > If we want to support hardware crypto for broadcast traffic on AP VLAN
> > interfaces we'd either need to switch to per station GTKs or need to
> > make drivers aware of VLAN interfaces. Not sure if it's worth it.
> > 
> > At least current rt2x00 devices won't be able to support that due to
> > the limited amount of available key space.

> Hmm, good point. Jouni, any comments? Lennert maybe?

I haven't looked at how the per-STA GTKs interface would apply here, but
since the broadcast keys are only used for TX, having multiple keys
should not be much of an issue for drivers that have similar design to
ath9k/ath5k as long as we can convince the driver to assign different
hw_key_idx for each key. So yes, there will need to be some knowledge of
different AP VLAN context to allow this to happen. Anyway, I would not
be too worried about starting with forced sw crypto for
broadcast/multicast frames in any other vif than the first one and
considering optimizations later should someone care enough.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: [PATCH] mac80211: Use sw crypto for GTKs on AP VLAN interfaces

[Helmut Schaa]

Am Donnerstag 18 November 2010 schrieb Johannes Berg:
> On Thu, 2010-11-18 at 16:36 +0100, Helmut Schaa wrote:
> > That means, broadcast traffic to and from stations associated to an AP
> > VLAN interface is encrypted and decrypted in software whereas broadcast
> > traffic to and from stations associated to the non-VLAN AP interface is
> > encrypted end decrypted in hardware.
> 
> Minor nit: bcast traffic from stations is never decrypted by these keys
> since stations never send real bcast frames -- just remove the decyrpted
> part and "from stations" part :-)

Ah, yes, you're right. I'll update the comment accordingly ...

Helmut

[PATCHv2] mac80211: Disable hw crypto for GTKs on AP VLAN interfaces

[Helmut Schaa]

When using AP VLAN interfaces, each VLAN interface should be in its own
broadcast domain. Hostapd achieves this by assigning different GTKs to
different AP VLAN interfaces.

However, mac80211 drivers are not aware of AP VLAN interfaces and as
such mac80211 sends the GTK to the driver in the context of the base AP
mode interface. This causes problems when multiple AP VLAN interfaces
are used since the driver will use the same key slot for the different
GTKs (there's no way for the driver to distinguish the different GTKs
from different AP VLAN interfaces). Thus, only the clients associated
to one AP VLAN interface (the one that was created last) can actually
use broadcast traffic.

Fix this by not programming any GTKs for AP VLAN interfaces into the hw
but fall back to using software crypto. The GTK for the underlying AP
interface is still sent to the driver.

That means, broadcast traffic to stations associated to an AP VLAN
interface is encrypted in software whereas broadcast traffic to
stations associated to the non-VLAN AP interface is encrypted in
hardware.

Cc: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
---

Changes since v1:
* Fix commit message

 net/mac80211/key.c |    9 ++++++++-
 1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/net/mac80211/key.c b/net/mac80211/key.c
index ccd676b..72df1ca 100644
--- a/net/mac80211/key.c
+++ b/net/mac80211/key.c
@@ -84,10 +84,17 @@ static int ieee80211_key_enable_hw_accel(struct ieee80211_key *key)
 		goto out_unsupported;
 
 	sdata = key->sdata;
-	if (sdata->vif.type == NL80211_IFTYPE_AP_VLAN)
+	if (sdata->vif.type == NL80211_IFTYPE_AP_VLAN) {
+		/*
+		 * The driver doesn't know anything about VLAN interfaces.
+		 * Hence, don't send GTKs for VLAN interfaces to the driver.
+		 */
+		if (!(key->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE))
+			goto out_unsupported;
 		sdata = container_of(sdata->bss,
 				     struct ieee80211_sub_if_data,
 				     u.ap);
+	}
 
 	ret = drv_set_key(key->local, SET_KEY, sdata, sta, &key->conf);
 
-- 
1.7.1