1. 20 Apr, 2023 3 commits
    • Johannes Berg's avatar
      wifi: iwlwifi: mvm: fix MIC removal confusion · 7b41a99c
      Johannes Berg authored
      The RADA/firmware collaborate on MIC stripping in the following
      way:
       - the firmware fills the IWL_RX_MPDU_MFLG1_MIC_CRC_LEN_MASK
         value for how many words need to be removed at the end of
         the frame, CRC and, if decryption was done, MIC
       - if the RADA is active, it will
         - remove that much from the end of the frame
         - zero the value in IWL_RX_MPDU_MFLG1_MIC_CRC_LEN_MASK
      
      As a consequence, the only thing the driver should need to do
      is to
       - unconditionally tell mac80211 that the MIC was removed
         if decryption was already done
       - remove as much as IWL_RX_MPDU_MFLG1_MIC_CRC_LEN_MASK says
         at the end of the frame, since either RADA did it and then
         the value is 0, or RADA was disabled and then the value is
         whatever should be removed to strip both CRC & MIC
      
      However, all this code was historically grown and getting a
      bit confused. Originally, we were indicating that the MIC was
      not stripped, which is the version of the code upstreamed in
      commit 780e87c2 ("iwlwifi: mvm: add 9000 series RX processing")
      which indicated RX_FLAG_DECRYPTED in iwl_mvm_rx_crypto().
      
      We later had a commit to change that to also indicate that the
      MIC was stripped, adding RX_FLAG_MIC_STRIPPED. However, this was
      then "fixed" later to only do that conditionally on RADA being
      enabled, since otherwise RADA didn't strip the MIC bytes yet.
      At the time, we were also always including the FCS if the RADA
      was not enabled, so that was still broken wrt. the FCS if the
      RADA isn't enabled - but that's a pretty rare case. Notably
      though, it does happen for management frames, where we do need
      to remove the MIC and CRC but the RADA is disabled.
      
      Later, in commit 40a0b38d ("iwlwifi: mvm: Fix calculation of
      frame length"), we changed this again, upstream this was just a
      single commit, but internally it was split into first the correct
      commit and then an additional fix that reduced the number of bytes
      that are removed by crypt_len. Note that this is clearly wrong
      since crypt_len indicates the length of the PN header (always 8),
      not the length of the MIC (8 or 16 depending on algorithm).
      However, this additional fix mostly canceled the other bugs,
      apart from the confusion about the size of the MIC.
      
      To fix this correctly, remove all those additional workarounds.
      We really should always indicate to mac80211 the MIC was stripped
      (it cannot use it anyway if decryption was already done), and also
      always actually remove it and the CRC regardless of the RADA being
      enabled or not. That's simple though, the value indicated in the
      metadata is zeroed by the RADA if it's enabled and used the value,
      so there's no need to check if it's enabled or not.
      
      Notably then, this fixes the MIC size confusion, letting us receive
      GCMP-256 encrypted management frames correctly that would otherwise
      be reported to mac80211 8 bytes too short since the RADA is turned
      off for them, crypt_len is 8, but the MIC size is 16, so when we do
      the adjustment based on IWL_RX_MPDU_MFLG1_MIC_CRC_LEN_MASK (which
      indicates 20 bytes to remove) we remove 12 bytes but indicate then
      to mac80211 the MIC is still present, so mac80211 again removes the
      MIC of 16 bytes, for an overall removal of 28 rather than 20 bytes.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarGregory Greenman <gregory.greenman@intel.com>
      Link: https://lore.kernel.org/r/20230418122405.81345b6ab0cd.Ibe0348defb6cce11c99929a1f049e60b5cfc150c@changeidSigned-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      7b41a99c
    • Johannes Berg's avatar
      wifi: iwlwifi: fw: fix memory leak in debugfs · 3d90d2f4
      Johannes Berg authored
      Fix a memory leak that occurs when reading the fw_info
      file all the way, since we return NULL indicating no
      more data, but don't free the status tracking object.
      
      Fixes: 36dfe9ac ("iwlwifi: dump api version in yaml format")
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarGregory Greenman <gregory.greenman@intel.com>
      Link: https://lore.kernel.org/r/20230418122405.239e501b3b8d.I4268f87809ef91209cbcd748eee0863195e70fa2@changeidSigned-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      3d90d2f4
    • Mukesh Sisodiya's avatar
  2. 19 Apr, 2023 1 commit
  3. 18 Apr, 2023 16 commits
  4. 17 Apr, 2023 20 commits