From: Alexander Wetzel <alexander@wetzel-home.de>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [RFC PATCH v3 04/12] mac80211: Compatibility Extended Key ID support
Date: Sat, 23 Feb 2019 23:50:17 +0100 [thread overview]
Message-ID: <028ee74c-0a34-44a6-d11b-f8a37706d86e@wetzel-home.de> (raw)
In-Reply-To: <b963b4257bba8b5423b93dd58c5828604fc07df4.camel@sipsolutions.net>
> On Thu, 2019-02-21 at 21:07 +0100, Alexander Wetzel wrote:
>>>
>>>> + if (!ext_native && key->flags & KEY_FLAG_UPLOADED_TO_HARDWARE) {
>>>> + key->flags |= KEY_FLAG_RX_SW_CRYPTO;
>>>> + /* Activate Rx crypto offload after max 10s when idle */
>>>> + ieee80211_queue_delayed_work(&local->hw, &sta->ext_key_compat_wk,
>>>> + round_jiffies_relative(HZ * 10));
>>>> + }
>>>
>>> Is there much point in this?
>>>
>>>> + if (unlikely(rx->key->flags & KEY_FLAG_RX_SW_CRYPTO)) {
>>>> + rx->key->flags &= ~KEY_FLAG_RX_SW_CRYPTO;
>>>> + cancel_delayed_work(&rx->sta->ext_key_compat_wk);
>>>> + ieee80211_queue_delayed_work(&rx->local->hw,
>>>> + &rx->sta->ext_key_compat_wk, 0);
>>>> + }
>>>
>>> We'll almost certainly do it from here, so never exercise the other
>>> path?
>>
>> This is mostly to have a definite time we know the new key is used also
>> for RX. In probably 99.9% of all cases it will be triggered from the Rx
>> path.
>> Some special purpose devices may not send any packets for a long time
>> and trigger the fallback, as (wrong) firewall rules. (I've e.g. tested
>> it by dropping all outgoing packets on the remote sta.)
>>
>> The idea was to be sure that a rekey intervall >10s prevents activating
>> Rx crypt when rekeying the next key. Which now sounds kind of thin...
>
> Not sure I even understand this?
>
> You meant "Rx crypto offload"? I'm not really sure we _care_ that much?
>
> Then again, an issue may be that some firmware may want (need) the keys
> for RX so it can look at certain frames (action frames?) itself. So if
> we never install the RX key and then only get an action frame that the
> firmware should handle, we lose. Such firmware could not support COMPAT
> mode then I guess, which may mean a bunch of iwlwifi devices shouldn't
> use COMPAT mode.
We still seem to have a problem understanding each other here. That
sounds like something we have to sort out with the RFC patch series to
avoid bad surprises later... It's probably nothing, but here we go:-)
First, COMPAT drivers must not have any key installed for Rx offload in
Hw. Any active Rx key will be changed to a Tx only key with mac80211
taking over the Rx decryption in software.
That is bad, weak CPU devices asked to take over decryption will be not
able to handle the same load as with HW. (My test router can't and with
Sw crypto I'm around 20MBit/s slower. The router even become
unresponsive on a shell when stressing it in a quick test some weeks
ago, with a single client uploading.)
So we try to handle as few packets as possible with SW crypto and as
soon as we see a packet encrypted with the new key activate Rx crypto
with the new key again. Any packets send with the old key after that are
very likely mangled by the Rx crypto offload and lost and part of the
price we have to pay for being able to use extended Key ID with cards
never designed for it and at least with traffic between ath9k/iwldvm not
an issue at all.
But it's of course all that is irrelevant when we are no packets to
decrypt and the code sample above starting the discussion. That is
handling a very rare corner case I reproduced by dropping all outgoing
packets with iptables on the remote station. EAPOL packets of course
don't care about iptable rules and the key could still be rekeyed, but
EAPOL frames were the only traffic possible and since the handshake
still use the outgoing key the receiving station never got a packet
encrypted with the new key, preventing it to activate Rx offload. So 10s
after the rekey the "fallback" mechanism kicked in.
Not installing the Rx key after 10s as a fallback has no real downsides,
it only may break the assumption of someone debugging a problem that at
10s after we installed the key to mac80211 the Hw crypto will be active
again.
Without the fallback it's just something like extremely likely and may
be not true in unusual setups or for problems affecting the Rx path.
Long story short, if you don't like the fallback activating mechanism
for no Rx packets seen we can simply drop it.
As you said it's a rare case and not handling it only chances what you
assume from what you know for sure during debugging of a problem.
Management Frame crypto is not affected by COMPAT mode workarounds or
even by Extended Key ID at all, or I have a big flaw in my understanding:
Managment frames (802.11w) and for my understanding therefore also
action frames do not use the keys PTK keys (IDs 0+1) but 4+5 and never
touch the QoS MPDUs Extended Key ID is all about.
But after figuring that much out I ignored it...
Alexander
next prev parent reply other threads:[~2019-02-23 23:29 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-10 21:06 [RFC PATCH v3 00/12] Draft for Extended Key ID support Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 01/12] mac80211: Optimize tailroom_needed update checks Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 02/12] nl80211/cfg80211: Extended Key ID support Alexander Wetzel
2019-02-15 10:52 ` Johannes Berg
2019-02-17 19:19 ` Alexander Wetzel
2019-02-22 8:30 ` Johannes Berg
2019-02-22 23:04 ` Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 03/12] mac80211: IEEE 802.11 " Alexander Wetzel
2019-02-15 11:06 ` Johannes Berg
2019-02-19 20:58 ` Alexander Wetzel
2019-02-21 19:47 ` Alexander Wetzel
2019-02-22 8:41 ` Johannes Berg
2019-02-23 21:02 ` Alexander Wetzel
2019-03-01 20:43 ` Alexander Wetzel
2019-02-23 17:26 ` Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 04/12] mac80211: Compatibility " Alexander Wetzel
2019-02-15 11:09 ` Johannes Berg
2019-02-21 20:07 ` Alexander Wetzel
2019-02-22 8:53 ` Johannes Berg
2019-02-23 22:50 ` Alexander Wetzel [this message]
2019-02-10 21:06 ` [RFC PATCH v3 05/12] mac80211: Mark A-MPDU keyid borders for drivers Alexander Wetzel
2019-02-15 11:50 ` Johannes Berg
2019-02-21 21:20 ` Alexander Wetzel
2019-02-22 8:51 ` Johannes Berg
2019-02-23 21:47 ` Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 06/12] mac80211_hwsim: Ext Key ID support (NATIVE) Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 07/12] iwlwifi: Extended " Alexander Wetzel
2019-02-15 11:52 ` Johannes Berg
2019-02-22 20:50 ` Alexander Wetzel
2019-02-22 21:06 ` Johannes Berg
2019-02-24 13:04 ` Alexander Wetzel
2019-04-08 20:10 ` Johannes Berg
2019-04-10 20:46 ` Alexander Wetzel
2019-04-12 9:51 ` Johannes Berg
2019-04-14 16:12 ` Alexander Wetzel
2019-04-15 8:44 ` Johannes Berg
2019-04-15 20:09 ` Alexander Wetzel
2019-04-16 9:31 ` Johannes Berg
2019-04-16 18:28 ` Alexander Wetzel
2019-04-16 19:11 ` Johannes Berg
2019-04-16 21:32 ` Alexander Wetzel
2019-04-12 11:19 ` Johannes Berg
2019-02-10 21:06 ` [RFC PATCH v3 08/12] iwlwifi: dvm - EXT_KEY_ID A-MPDU API update Alexander Wetzel
2019-02-15 11:54 ` Johannes Berg
2019-02-22 21:15 ` Alexander Wetzel
2019-02-22 21:20 ` Johannes Berg
2019-02-10 21:06 ` [RFC PATCH v3 09/12] ath: Basic Extended Key ID support (COMPAT+NATIVE) Alexander Wetzel
2019-02-13 11:05 ` Kalle Valo
2019-02-13 23:15 ` Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 10/12] ath5k: ath_key_config() API compatibility update Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 11/12] ath9k: Extended Key ID support (COMPAT) Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 12/12] ath9k: EXT_KEY_ID A-MPDU API update Alexander Wetzel
2019-02-15 11:10 ` [RFC PATCH v3 00/12] Draft for Extended Key ID support Johannes Berg
2019-02-21 20:44 ` Alexander Wetzel
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=028ee74c-0a34-44a6-d11b-f8a37706d86e@wetzel-home.de \
--to=alexander@wetzel-home.de \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@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).