linux.git/net/mac80211/key.c, branch v5.7

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net

2020-03-30T04:25:29+00:00

Minor comment conflict in mac80211.

Signed-off-by: David S. Miller

mac80211: drop data frames without key on encrypted links

2020-03-26T14:49:24+00:00

If we know that we have an encrypted link (based on having had
a key configured for TX in the past) then drop all data frames
in the key selection handler if there's no key anymore.

This fixes an issue with mac80211 internal TXQs - there we can
buffer frames for an encrypted link, but then if the key is no
longer there when they're dequeued, the frames are sent without
encryption. This happens if a station is disconnected while the
frames are still on the TXQ.

Detecting that a link should be encrypted based on a first key
having been configured for TX is fine as there are no use cases
for a connection going from with encryption to no encryption.
With extended key IDs, however, there is a case of having a key
configured for only decryption, so we can't just trigger this
behaviour on a key being configured.

Cc: stable@vger.kernel.org
Reported-by: Jouni Malinen 
Signed-off-by: Johannes Berg 
Signed-off-by: Luca Coelho 
Link: https://lore.kernel.org/r/iwlwifi.20200326150855.6865c7f28a14.I9fb1d911b064262d33e33dfba730cdeef83926ca@changeid
Signed-off-by: Johannes Berg

mac80211: Support BIGTK configuration for Beacon protection

2020-02-24T09:35:57+00:00

Extend mac80211 key configuration to support the new BIGTK with key
index values 6 and 7. Support for actually protecting Beacon frames
(adding the MME in AP mode and checking it in STA mode) is covered in
separate commits.

Signed-off-by: Jouni Malinen 
Link: https://lore.kernel.org/r/20200222132548.20835-3-jouni@codeaurora.org
Signed-off-by: Johannes Berg

mac80211: fix 11w when using encapsulation offloading

2020-02-07T10:31:36+00:00

The 802.11 encapsulation returned early when setting up the keys in case
offloading was enabled. This causes ieee802.11w to not work anymore. Fix
this by moving the check for offloading into the switch/case construct and
allowing CCMP/GCMP keys. With this patch applied ieee80211w works again
when enabling offloading.

Fixes: 50ff477a8639 ("mac80211: add 802.11 encapsulation offloading support")
Reported-by: Maharaja Kennadyrajan 
Signed-off-by: John Crispin 
Link: https://lore.kernel.org/r/20200203122812.18993-1-john@phrozen.org
Signed-off-by: Johannes Berg

mac80211: add 802.11 encapsulation offloading support

2019-12-13T19:02:36+00:00

This patch adds a new transmit path for hardware that supports 802.11
encapsulation offloading. In those cases 802.3 frames get passed
directly to the driver allowing the hardware to handle the encapsulation.
Some features such as monitor mode and TKIP would break when encapsulation
offloading is enabled. If any of these get enabled, the code will alwyas
fallback to the normal sw encapsulation data path.

The patch defines a secondary netdev_ops struct that the device gets
assigned if 802.11 encap support is available and enabled. The driver
needs to enable the support on a per vif basis if it finds that all
pre-reqs are meet.

Signed-off-by: Vasanthakumar Thiagarajan 
Signed-off-by: John Crispin 
Link: https://lore.kernel.org/r/20191125100438.16539-1-john@phrozen.org
[reword comments, remove SUPPORTS_80211_ENCAP HW flag, minor cleanups]
Signed-off-by: Johannes Berg

mac80211: don't check if key is NULL in ieee80211_key_link()

2019-09-11T07:33:28+00:00

We already assume that key is not NULL and dereference it in a few
other places before we check whether it is NULL, so the check is
unnecessary.  Remove it.

Fixes: 96fc6efb9ad9 ("mac80211: IEEE 802.11 Extended Key ID support")
Signed-off-by: Luca Coelho 
Link: https://lore.kernel.org/r/20190830112451.21655-8-luca@coelho.fi
Signed-off-by: Johannes Berg

mac80211: clear crypto tx tailroom counter upon keys enable

2019-09-11T07:33:28+00:00

In case we got a fw restart while roaming from encrypted AP to
non-encrypted one, we might end up with hitting a warning on the pending
counter crypto_tx_tailroom_pending_dec having a non-zero value.

The following comment taken from net/mac80211/key.c explains the rational
for the delayed tailroom needed:

	/*
	* The reason for the delayed tailroom needed decrementing is to
	* make roaming faster: during roaming, all keys are first deleted
	* and then new keys are installed. The first new key causes the
	* crypto_tx_tailroom_needed_cnt to go from 0 to 1, which invokes
	* the cost of synchronize_net() (which can be slow). Avoid this
	* by deferring the crypto_tx_tailroom_needed_cnt decrementing on
	* key removal for a while, so if we roam the value is larger than
	* zero and no 0->1 transition happens.
	*
	* The cost is that if the AP switching was from an AP with keys
	* to one without, we still allocate tailroom while it would no
	* longer be needed. However, in the typical (fast) roaming case
	* within an ESS this usually won't happen.
	*/

The next flow lead to the warning eventually reported as a bug:
1. Disconnect from encrypted AP
2. Set crypto_tx_tailroom_pending_dec = 1 for the key
3. Schedule work
4. Reconnect to non-encrypted AP
5. Add a new key, setting the tailroom counter = 1
6. Got FW restart while pending counter is set ---> hit the warning

While on it, the ieee80211_reset_crypto_tx_tailroom() func was merged into
its single caller ieee80211_reenable_keys (previously called
ieee80211_enable_keys). Also, we reset the crypto_tx_tailroom_pending_dec
and remove the counters warning as we just reset both.

Signed-off-by: Lior Cohen 
Signed-off-by: Luca Coelho 
Link: https://lore.kernel.org/r/20190830112451.21655-7-luca@coelho.fi
Signed-off-by: Johannes Berg

mac80211: remove unnecessary key condition

2019-09-11T07:33:28+00:00

When we reach this point, the key cannot be NULL. Remove the condition
that suggests otherwise.

Signed-off-by: Johannes Berg 
Signed-off-by: Luca Coelho 
Link: https://lore.kernel.org/r/20190830112451.21655-6-luca@coelho.fi
Signed-off-by: Johannes Berg

mac80211: AMPDU handling for rekeys with Extended Key ID

2019-07-26T11:29:10+00:00

Extended Key ID allows A-MPDU sessions while rekeying as long as each
A-MPDU aggregates only MPDUs with one keyid together.

Drivers able to segregate MPDUs accordingly can tell mac80211 to not
stop A-MPDU sessions when rekeying by setting the new flag
IEEE80211_HW_AMPDU_KEYBORDER_SUPPORT.

Signed-off-by: Alexander Wetzel 
Link: https://lore.kernel.org/r/20190629195015.19680-3-alexander@wetzel-home.de
Signed-off-by: Johannes Berg

mac80211: Simplify Extended Key ID API

2019-07-26T11:28:59+00:00

1) Drop IEEE80211_HW_EXT_KEY_ID_NATIVE and let drivers directly set
   the NL80211_EXT_FEATURE_EXT_KEY_ID flag.

2) Drop IEEE80211_HW_NO_AMPDU_KEYBORDER_SUPPORT and simply assume all
   drivers are unable to handle A-MPDU key borders.

The new Extended Key ID API now requires all mac80211 drivers to set
NL80211_EXT_FEATURE_EXT_KEY_ID when they implement set_key() and can
handle Extended Key ID. For drivers not providing set_key() mac80211
itself enables Extended Key ID support, using the internal SW crypto
services.

Signed-off-by: Alexander Wetzel 
Link: https://lore.kernel.org/r/20190629195015.19680-2-alexander@wetzel-home.de
Signed-off-by: Johannes Berg