Re: [PATCH] wifi: mac80211: defer AP-side FT key upload until association

Hi Johannes,

> I think I'd mostly like to understand how it interacts. SMD Transition
> won't actually handle this particular path, but client-side has a similar
> issue where the key is available before the STA entry for the AP is fully
> available.

I compared this with your posted group-key RFC. Its SMD-specific GTK/CIGTK
slots are separate from this pairwise PTK path, but the generic key-slot
refactoring also covers sta->ptk[] and moves the ASSOC gate. This AP-side
mechanism requires an existing, lookupable sta_info and a PTK slot, so it
cannot represent a key arriving before that point or handle the earlier
client-side phase as-is. The deferred flag can still live on the individual
ieee80211_key after rebasing. With the new tailroom handling, the ASSOC-time
retry would call ieee80211_key_enable_hw_accel(key, true), since it is
updating an already-linked key and must adjust tailroom accounting after a
successful hardware upload.

> Now looking at the code I also wonder devices could just deal with the key
> installed before the station is marked associated?

mt7915's set_key() currently returns -EOPNOTSUPP until its AUTH-to-ASSOC setup
marks the WCID ready, while wlcore allocates its per-peer firmware HLID during
that transition. Outside the EPP-specific
NL80211_EXT_FEATURE_ASSOC_FRAME_ENCRYPTION opt-in, I could not find a mac80211
capability that guarantees early set_key() is safe for an ordinary AP-side FT
PTK, so I did not assume that every driver can be called early.

The OpenWrt PR also provides a useful A/B result for the
SW_CRYPTO_CONTROL interaction. The initial revision deferred the key with
ret left as -EOPNOTSUPP. It removed the error on mt76, but the error remained
on EAP1200H and OnHub, whose standard OpenWrt profiles use ath10k-ct. A
follow-up moved the deferred branch ahead of the sta->uploaded check and set
ret = 1. The subsequent report for the same device set showed the error gone:

https://github.com/openwrt/openwrt/pull/23181#issuecomment-4500287395

The revised path removed the reported error on those configurations. This is
consistent with synthesizing ret = 1 having permitted software crypto, but it
does not show whether ath10k accepts set_key() before ASSOC, because the
callback was skipped, or whether the key was later uploaded to hardware. It
also illustrates precisely the SW_CRYPTO_CONTROL issue you raised: only an
actual return value of 1 from the driver authorizes software crypto. I do not
want mac80211 to synthesize that permission.

For an upstream solution, would you prefer a genuine dormant-key state, where
the key is neither uploaded nor authorized for software use until ASSOC and
upload failure has a defined path, or should affected drivers handle the early
key themselves, either by installing it immediately or caching it until their
peer setup completes? The latter could use an explicit capability so mac80211
relaxes the ASSOC gate only for drivers supporting that ordering. For a
SW_CRYPTO_CONTROL driver that cannot install or cache the key early, an
explicit return value of 1 followed by a mac80211 retry at ASSOC is another
possible contract. I would avoid adding that, however, and understood your
question as suggesting that driver-side handling should be investigated first.

I have kept v2 local while clarifying this direction and dropped the stable
CC as suggested.

Best,
Andrea