Bug 277996 - LinuxKPI w/ LKPI_80211_HW_CRYPTO: iwlwifi development: hw based encryption not work
Summary: LinuxKPI w/ LKPI_80211_HW_CRYPTO: iwlwifi development: hw based encryption no...
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: wireless (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: Cheng Cui
URL:
Keywords: tracking
Depends on:
Blocks: 277095
  Show dependency treegraph
 
Reported: 2024-03-27 19:04 UTC by Cheng Cui
Modified: 2024-04-16 20:33 UTC (History)
2 users (show)

See Also:


Attachments
packet capture with hw based encryption (546 bytes, application/vnd.tcpdump.pcap)
2024-03-27 19:04 UTC, Cheng Cui
no flags Details
packets with sw based encryption (31.64 KB, application/vnd.tcpdump.pcap)
2024-03-27 19:05 UTC, Cheng Cui
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Cheng Cui freebsd_committer freebsd_triage 2024-03-27 19:04:41 UTC
Created attachment 249521 [details]
packet capture with hw based encryption

On top of review D44463 (multi-key support), the current hw based encryption is not working, although the unicast and broadcast keys are mapped correctly and the corresponding hw keys are setup correctly.

Initial investigation shows that no CCMP parameters are added in packets under `LKPI_80211_HW_CRYPTO `, but the sw CCMP parameters are added in packets under sw encryption. See the attached packet captures of hw and sw enabled traffic from the same station.
Comment 1 Cheng Cui freebsd_committer freebsd_triage 2024-03-27 19:05:20 UTC
Created attachment 249522 [details]
packets with sw based encryption
Comment 2 Cheng Cui freebsd_committer freebsd_triage 2024-04-08 15:27:05 UTC
Current observations from my investigation are:
[1] In Linux, key_flags value is either 2(IWL_SEC_KEY_FLAG_CIPHER_CCMP) or 66
    (IWL_SEC_KEY_FLAG_CIPHER_CCMP | IWL_SEC_KEY_FLAG_MCAST_KEY) for a unicast
    or a broadcast key. The current LinuxKPI code does not handle such flag
    values. However, a test with brute force assignment of flag
    IEEE80211_KEY_FLAG_PAIRWISE does not make it work either. So it requires
    further tests.

[2] Also ieee80211_tx_info_flags values are different between LinuxKPI and the
    Linux verion. Need more time to check on this.

[3] Current control block size of `cb[64]` in `struct sk_buff` from LinuxKPI is
    larger than the Linux version. Although the current sizeof 
    `struct ieee80211_tx_info` is 56 bytes, which fits in the 64 bytes `cb`,
    I am not sure if this is a potential problem as the Linux version of the
    struct is 48 bytes, which fits into the Linux sk_buff `cb[48]` control
    block.
Comment 3 Cheng Cui freebsd_committer freebsd_triage 2024-04-10 20:34:58 UTC
I am able to reproduce the same problem in Linux. The reproduce method is if the info->control.hw_key is nullified right before iwl_mvm_set_tx_params() inside iwl_mvm_tx_mpdu(), the same encryption failure will show up.

Now, need to dig into iwl_mvm_set_tx_params().
Comment 4 Cheng Cui freebsd_committer freebsd_triage 2024-04-16 20:33:13 UTC
Here is the backtraces of a hw ucast key setup in Linux. According to
ieee80211_tx_h_select_key(), info->control.hw_key shall be empty if not needed.

nl80211_new_key (cfg80211: parse key, validate key)
 rdev_add_key
  ieee80211_add_key (mac80211: alloc ieee80211_key, add IEEE80211_KEY_FLAG_RX_MGMT by vif.type)
   ieee80211_key_link (mac80211: link the key to sta)
    ieee80211_key_replace (mac80211)
     ieee80211_key_enable_hw_accel (mac80211: add KEY_FLAG_UPLOADED_TO_HARDWARE if drv_set_key returns success, this flag is used for ieee80211_tx_h_select_key())
      drv_set_key (mac80211)
       iwl_mvm_mac_set_key (iwlmvm)
        iwl_mvm_sec_key_add (iwlmvm: set keyconf->hw_key_idx = 0)
         iwl_mvm_mld_send_key (iwlmvm)
          iwl_mvm_send_cmd_pdu (iwlmvm)