linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jerome Pouiller <Jerome.Pouiller@silabs.com>
To: devel@driverdev.osuosl.org, linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Kalle Valo" <kvalo@codeaurora.org>,
	"David S . Miller" <davem@davemloft.net>,
	"Jérôme Pouiller" <jerome.pouiller@silabs.com>
Subject: [PATCH 11/13] staging: wfx: fix CCMP/TKIP replay protection
Date: Wed,  1 Jul 2020 17:07:05 +0200	[thread overview]
Message-ID: <20200701150707.222985-12-Jerome.Pouiller@silabs.com> (raw)
In-Reply-To: <20200701150707.222985-1-Jerome.Pouiller@silabs.com>

From: Jérôme Pouiller <jerome.pouiller@silabs.com>

To enable the TKIP/CCMP replay protection, the frames has to be
processed in the right order. However, the device is not able to
re-order the frames during BlockAck sessions.

Mac80211 is able to reorder the frames, but it need the information
about the BlockAck sessions start and stop. Unfortunately, since the
BlockAck is fully handled by the hardware, these frames were not
forwarded to the host. So, if the driver ask to mac80211 to apply the
replay protection, it drop all misordered frames.

So, until now, the driver explicitly asked to mac80211 to not apply
the CCMP/TKIP replay protection.

The situation has changed with the API 3.4 of the device firmware. The
firmware forward the BlockAck information. Mac80211 is now able to
correctly reorder the frames. There is no more reasons to drop
cryptographic data.

This patch also impact the older firmwares. There will be a performance
impact on these firmware (since the misordered frames will dropped).
However, we can't keep the replay protection disabled.

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
---
 drivers/staging/wfx/data_rx.c | 31 ++++++++++++++++++++++++++-----
 drivers/staging/wfx/data_tx.c |  3 ++-
 2 files changed, 28 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/wfx/data_rx.c b/drivers/staging/wfx/data_rx.c
index 60e2e5cb4656a..6fb0788807426 100644
--- a/drivers/staging/wfx/data_rx.c
+++ b/drivers/staging/wfx/data_rx.c
@@ -13,6 +13,24 @@
 #include "bh.h"
 #include "sta.h"
 
+static void wfx_rx_handle_ba(struct wfx_vif *wvif, struct ieee80211_mgmt *mgmt)
+{
+	int params, tid;
+
+	switch (mgmt->u.action.u.addba_req.action_code) {
+	case WLAN_ACTION_ADDBA_REQ:
+		params = le16_to_cpu(mgmt->u.action.u.addba_req.capab);
+		tid = (params & IEEE80211_ADDBA_PARAM_TID_MASK) >> 2;
+		ieee80211_start_rx_ba_session_offl(wvif->vif, mgmt->sa, tid);
+		break;
+	case WLAN_ACTION_DELBA:
+		params = le16_to_cpu(mgmt->u.action.u.delba.params);
+		tid = (params &  IEEE80211_DELBA_PARAM_TID_MASK) >> 12;
+		ieee80211_stop_rx_ba_session_offl(wvif->vif, mgmt->sa, tid);
+		break;
+	}
+}
+
 void wfx_rx_cb(struct wfx_vif *wvif,
 	       const struct hif_ind_rx *arg, struct sk_buff *skb)
 {
@@ -53,15 +71,18 @@ void wfx_rx_cb(struct wfx_vif *wvif,
 	hdr->antenna = 0;
 
 	if (arg->rx_flags.encryp)
-		hdr->flag |= RX_FLAG_DECRYPTED | RX_FLAG_PN_VALIDATED;
+		hdr->flag |= RX_FLAG_DECRYPTED;
 
-	/* Filter block ACK negotiation: fully controlled by firmware */
+	// Block ack negociation is offloaded by the firmware. However,
+	// re-ordering must be done by the mac80211.
 	if (ieee80211_is_action(frame->frame_control) &&
-	    arg->rx_flags.match_uc_addr &&
-	    mgmt->u.action.category == WLAN_CATEGORY_BACK)
+	    mgmt->u.action.category == WLAN_CATEGORY_BACK &&
+	    skb->len > IEEE80211_MIN_ACTION_SIZE) {
+		wfx_rx_handle_ba(wvif, mgmt);
 		goto drop;
+	}
+
 	ieee80211_rx_irqsafe(wvif->wdev->hw, skb);
-
 	return;
 
 drop:
diff --git a/drivers/staging/wfx/data_tx.c b/drivers/staging/wfx/data_tx.c
index 5c744d9c8c114..3acf4eb0214dc 100644
--- a/drivers/staging/wfx/data_tx.c
+++ b/drivers/staging/wfx/data_tx.c
@@ -418,7 +418,8 @@ void wfx_tx(struct ieee80211_hw *hw, struct ieee80211_tx_control *control,
 		wvif = wvif_iterate(wdev, NULL);
 	if (WARN_ON(!wvif))
 		goto drop;
-	// FIXME: why?
+	// Because of TX_AMPDU_SETUP_IN_HW, mac80211 does not try to send any
+	// BlockAck session management frame. The check below exist just in case.
 	if (ieee80211_is_action_back(hdr)) {
 		dev_info(wdev->dev, "drop BA action\n");
 		goto drop;
-- 
2.27.0


  parent reply	other threads:[~2020-07-01 15:08 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-01 15:06 [PATCH 00/13] staging: wfx: multiple fixes Jerome Pouiller
2020-07-01 15:06 ` [PATCH 01/13] staging: wfx: associate tx_queues to vifs Jerome Pouiller
2020-07-01 15:06 ` [PATCH 02/13] staging: wfx: check the vif ID of the Tx confirmations Jerome Pouiller
2020-07-01 15:06 ` [PATCH 03/13] staging: wfx: correctly retrieve vif ID from Tx confirmation Jerome Pouiller
2020-07-01 15:06 ` [PATCH 04/13] staging: wfx: add tracepoint "queues_stats" Jerome Pouiller
2020-07-01 15:06 ` [PATCH 05/13] staging: wfx: load the firmware faster Jerome Pouiller
2020-07-01 15:07 ` [PATCH 06/13] staging: wfx: improve protection against malformed HIF messages Jerome Pouiller
2020-07-01 15:07 ` [PATCH 07/13] staging: wfx: fix unexpected calls to ieee80211_sta_set_buffered() Jerome Pouiller
2020-07-01 15:07 ` [PATCH 08/13] staging: wfx: drop counter of buffered frames Jerome Pouiller
2020-07-01 15:07 ` [PATCH 09/13] staging: wfx: fix handling of frames without RSSI data Jerome Pouiller
2020-07-01 15:07 ` [PATCH 10/13] staging: wfx: simplify handling of encrypted frames Jerome Pouiller
2020-07-01 15:07 ` Jerome Pouiller [this message]
2020-07-01 15:07 ` [PATCH 12/13] staging: wfx: add a debugfs entry to force ps_timeout Jerome Pouiller
2020-07-01 15:07 ` [PATCH 13/13] staging: wfx: always enable FastPs in combo with new firmwares Jerome Pouiller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200701150707.222985-12-Jerome.Pouiller@silabs.com \
    --to=jerome.pouiller@silabs.com \
    --cc=davem@davemloft.net \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=kvalo@codeaurora.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).