Re: [PATCH wireless-next] wifi: mac80211: Fix AAD/Nonce computation for management frames with MLO

[Sai Pratyusha Magam <sai.magam@oss.qualcomm.com>]

On 1/14/2026 10:34 PM, Johannes Berg wrote:
> On Fri, 2026-01-09 at 15:33 +0530, Sai Pratyusha Magam wrote:
>>
>> Hi Johannes, I agree that by maintaining a local storage of the A1/A2/A3
>> link addresses before mac80211 translates them to the MLD addresses
>> would make things easy, i.e, they can directly be used for the
>> computations in the SW crypto. While this works well for the receive
>> path, on the Transmit path, mac80211 would still receive management
>> frames from hostapd with the MLD addresses, which again cannot be used
>> directly for the AAD/Nonce computations.
> 
> Fair point.
> 
> Thinking out loud: First, I think we can afford to separate TX and RX
> discussions.
> 
> For RX, I think we agree that it could be done much simpler by
> (conditionally, when we do translation in mac80211) keeping the pre-
> translation addresses, and passing them into the SW crypto. If not set,
> use the frame itself.
Agree that on the RX, crypto computations can use the copy of 
untranslated storage of addresses

> 
> Secondly, this all seems only relevant to hwsim. Do you think otherwise?
> Few drivers seem to use IEEE80211_KEY_FLAG_SW_MGMT_TX, so I think
> especially with MLO we can say that you simply _have_ to support TX
> encryption offload for EPPKE [1].
>
True, all of this is for the hwsim use case that uses the mac80211 based 
software crypto.


> Obviously we still want to have hwsim, but if this really is only for
> that then I feel we can still fairly easily implement TX encryption
> "offload"? After all, in RX we make decryption optional for every single
> frame - so if the device/driver didn't decrypt/validate the frame then
> mac80211 will. We also pass the key to the driver for each individual
> packet (struct ieee80211_tx_info::control::key). So doing the encryption
> in hwsim would be really simple if we export a function akin to
> ieee80211_tx_h_encrypt() that works on a single skb (which has the key
> pointer), sets up a single-frame struct ieee80211_tx_data and returns
> the skb from that [2].
>
"Implement TX encryption offload" - As I understand, your guidance is
towards implementing the Tx encryption in the mac80211_hwsim driver
Can you please kindly clarify if the understanding is correct?
In order to let mac80211_hwsim driver do the Tx encryption:
(1)Add support for key install to hwsim driver, i.e, 
mac80211_hwsim_ops::add_key, so mac80211 knows that the driver is going 
to do the encryption.
(2)A function similar to ieee80211_tx_h_encrypt() in the hwsim driver
that can do the actual encryption. Since mgmt frames need to use link 
addresses for crypto computations, possibly I could call 
ieee80211_encrypt_tx_skb() [2] after address translation to link 
addresses in mac80211_hwsim_tx() and since data frames need to use the 
MLD addresses, ieee80211_encrypt_tx_skb() can be called before the 
address translation to link addresses.


> While this may sound like a bit more work overall, I'm not even
> convinced that it's _that_ much more, and I it would also align hwsim
> more with how modern hardware works today anyway.
> 
> Any thoughts?
> 
> johannes
> 
> [1] and, it seems, correct unicast action frame encryption?
> [2] https://p.sipsolutions.net/154c5c86af7765fd.txt