1. 25 Nov, 2013 1 commit
  2. 11 Oct, 2013 1 commit
  3. 16 May, 2013 1 commit
  4. 11 Mar, 2013 3 commits
  5. 06 Mar, 2013 2 commits
    • Johannes Berg's avatar
      mac80211: defer tailroom counter manipulation when roaming · 8d1f7ecd
      Johannes Berg authored
      
      
      During roaming, the crypto_tx_tailroom_needed_cnt counter
      will often take values 2,1,0,1,2 because first keys are
      removed and then new keys are added. This is inefficient
      because during the 0->1 transition, synchronize_net must
      be called to avoid packet races, although typically no
      packets would be flowing during that time.
      
      To avoid that, defer the decrement (2->1, 1->0) when keys
      are removed (by half a second). This means the counter
      will really have the values 2,2,2,3,4 ... 2, thus never
      reaching 0 and having to do the 0->1 transition.
      
      Note that this patch entirely disregards the drivers for
      which this optimisation was done to start with, for them
      the key removal itself will be expensive because it has
      to synchronize_net() after the counter is incremented to
      remove the key from HW crypto. For them the sequence will
      look like this: 0,1,0,1,0,1,0,1,0 (*) which is clearly a
      lot more inefficient. This could be addressed separately,
      during key removal the 0->1->0 sequence isn't necessary.
      
      (*) it starts at 0 because HW crypto is on, then goes to
          1 when HW crypto is disabled for a key, then back to
          0 because the key is deleted; this happens for both
          keys in the example. When new keys are added, it goes
          to 1 first because they're added in software; when a
          key is moved to hardware it goes back to 0
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      8d1f7ecd
    • Stanislaw Gruszka's avatar
      mac80211: cleanup generic suspend/resume procedures · 12e7f517
      Stanislaw Gruszka authored
      
      
      Since now we disconnect before suspend, various code which save
      connection state can now be removed from suspend and resume
      procedure. Cleanup on resume side is smaller as ieee80211_reconfig()
      is also used for H/W restart.
      Signed-off-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      12e7f517
  6. 05 Dec, 2012 1 commit
  7. 19 Nov, 2012 1 commit
  8. 13 Jul, 2011 1 commit
    • Johannes Berg's avatar
      mac80211: allow driver to disconnect after resume · 95acac61
      Johannes Berg authored
      
      
      In WoWLAN, devices may use crypto keys for TX/RX
      and could also implement GTK rekeying. If the
      driver isn't able to retrieve replay counters and
      similar information from the device upon resume,
      or if the device isn't responsive due to platform
      issues, it isn't safe to keep the connection up
      as GTK rekey messages from during the sleep time
      could be replayed against it.
      
      The only protection against that is disconnecting
      from the AP. Modifying mac80211 to do that while
      it is resuming would be very complex and invasive
      in the case that the driver requires a reconfig,
      so do it after it has resumed completely. In that
      case, however, packets might be replayed since it
      can then only happen after TX/RX are up again, so
      mark keys for interfaces that need to disconnect
      as "tainted" and drop all packets that are sent
      or received with those keys.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      95acac61
  9. 08 Jul, 2011 6 commits
    • Johannes Berg's avatar
      mac80211: allow drivers to access key sequence counter · 3ea542d3
      Johannes Berg authored
      
      
      In order to implement GTK rekeying, the device needs
      to be able to encrypt frames with the right PN/IV and
      check the PN/IV in RX frames. To be able to tell it
      about all those counters, we need to be able to get
      them from mac80211, this adds the required API.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      3ea542d3
    • Johannes Berg's avatar
      mac80211: simplify RX PN/IV handling · 9e26297a
      Johannes Berg authored
      
      
      The current rx->queue value is slightly confusing.
      It is set to 16 on non-QoS frames, including data,
      and then used for sequence number and PN/IV checks.
      Until recently, we had a TKIP IV checking bug that
      had been introduced in 2008 to fix a seqno issue.
      Before that, we always used TID 0 for checking the
      PN or IV on non-QoS packets.
      
      Go back to the old status for PN/IV checks using
      the TID 0 counter for non-QoS by splitting up the
      rx->queue value into "seqno_idx" and "security_idx"
      in order to avoid confusion in the future. They
      each have special rules on the value used for non-
      QoS data frames.
      
      Since the handling is now unified, also revert the
      special TKIP handling from my patch
      "mac80211: fix TKIP replay vulnerability".
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      9e26297a
    • Johannes Berg's avatar
      mac80211: use AES_BLOCK_SIZE · 0cd20a27
      Johannes Berg authored
      
      
      mac80211 has a defnition of AES_BLOCK_SIZE and
      multiple definitions of AES_BLOCK_LEN. Remove
      them all and use crypto/aes.h.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      0cd20a27
    • Johannes Berg's avatar
      mac80211: fix CMAC races · 75396ae6
      Johannes Berg authored
      
      
      Just like TKIP and CCMP, CMAC has the PN race.
      It might not actually be possible to hit it now
      since there aren't multiple ACs for management
      frames, but fix it anyway.
      
      Also move scratch buffers onto the stack.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      75396ae6
    • Johannes Berg's avatar
      mac80211: fix CCMP races · aba83a0b
      Johannes Berg authored
      
      
      Since we can process multiple packets at the
      same time for different ACs, but the PN is
      allocated from a single counter, we need to
      use an atomic value there. Use atomic64_t to
      make this cheaper on 64-bit platforms, other
      platforms will support this through software
      emulation, see lib/atomic64.c.
      
      We also need to use an on-stack scratch buf
      so that multiple packets won't corrupt each
      others scratch buffers.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      aba83a0b
    • Johannes Berg's avatar
      mac80211: fix TKIP races, make API easier to use · 523b02ea
      Johannes Berg authored
      
      
      Our current TKIP code races against itself on TX
      since we can process multiple packets at the same
      time on different ACs, but they all share the TX
      context for TKIP. This can lead to bad IVs etc.
      
      Also, the crypto offload helper code just obtains
      the P1K/P2K from the cache, and can update it as
      well, but there's no guarantee that packets are
      really processed in order.
      
      To fix these issues, first introduce a spinlock
      that will protect the IV16/IV32 values in the TX
      context. This first step makes sure that we don't
      assign the same IV multiple times or get confused
      in other ways.
      
      Secondly, change the way the P1K cache works. I
      add a field "p1k_iv32" that stores the value of
      the IV32 when the P1K was last recomputed, and
      if different from the last time, then a new P1K
      is recomputed. This can cause the P1K computation
      to flip back and forth if packets are processed
      out of order. All this also happens under the new
      spinlock.
      
      Finally, because there are argument differences,
      split up the ieee80211_get_tkip_key() API into
      ieee80211_get_tkip_p1k() and ieee80211_get_tkip_p2k()
      and give them the correct arguments.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      523b02ea
  10. 16 May, 2011 1 commit
    • Johannes Berg's avatar
      mac80211: sparse RCU annotations · 40b275b6
      Johannes Berg authored
      
      
      This adds sparse RCU annotations to most of
      mac80211, only the mesh code remains to be
      done.
      
      Due the the previous patches, the annotations
      are pretty simple. The only thing that this
      actually changes is removing the RCU usage of
      key->sta in debugfs since this pointer isn't
      actually an RCU-managed pointer (it only has
      a single assignment done before the key even
      goes live). As that is otherwise harmless, I
      decided to make it part of this patch.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      40b275b6
  11. 12 May, 2011 1 commit
  12. 07 Mar, 2011 1 commit
  13. 13 Dec, 2010 1 commit
  14. 06 Oct, 2010 1 commit
  15. 27 Aug, 2010 1 commit
  16. 16 Aug, 2010 1 commit
  17. 27 Jul, 2010 1 commit
    • Jouni Malinen's avatar
      mac80211: Fix key freeing to handle unlinked keys · 32162a4d
      Jouni Malinen authored
      
      
      Key locking simplification removed key->sdata != NULL verification from
      ieee80211_key_free(). While that is fine for most use cases, there is one
      path where this function can be called with an unlinked key (i.e.,
      key->sdata == NULL && key->local == NULL). This results in a NULL pointer
      dereference with the current implementation. This is known to happen at
      least with FT protocol when wpa_supplicant tries to configure the key
      before association.
      
      Avoid the issue by passing in the local pointer to
      ieee80211_key_free(). In addition, do not clear the key from hw_accel
      or debugfs if it has not yet been added. At least the hw_accel one could
      trigger another NULL pointer dereference.
      Signed-off-by: default avatarJouni Malinen <j@w1.fi>
      Reviewed-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      32162a4d
  18. 15 Jun, 2010 1 commit
  19. 03 Jun, 2010 1 commit
  20. 22 Dec, 2009 1 commit
  21. 30 Oct, 2009 1 commit
    • Johannes Berg's avatar
      cfg80211/mac80211: use debugfs_remove_recursive · 7bcfaf2f
      Johannes Berg authored
      
      
      We can save a lot of code and pointers in the structs
      by using debugfs_remove_recursive().
      
      First, change cfg80211 to use debugfs_remove_recursive()
      so that drivers do not need to clean up any files they
      added to the per-wiphy debugfs (if and only if they are
      ok to be accessed until after wiphy_unregister!).
      
      Then also make mac80211 use debugfs_remove_recursive()
      where necessary -- it need not remove per-wiphy files
      as cfg80211 now removes those, but netdev etc. files
      still need to be handled but can now be removed without
      needing struct dentry pointers to all of them.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      7bcfaf2f
  22. 13 May, 2009 1 commit
    • Jouni Malinen's avatar
      nl80211: Add RSC configuration for new keys · faa8fdc8
      Jouni Malinen authored
      
      
      When setting a key with NL80211_CMD_NEW_KEY, we should allow the key
      sequence number (RSC) to be set in order to allow replay protection to
      work correctly for group keys. This patch documents this use for
      nl80211 and adds the couple of missing pieces in nl80211/cfg80211 and
      mac80211 to support this. In addition, WEXT SIOCSIWENCODEEXT compat
      processing in cfg80211 is extended to handle the RSC (this was already
      specified in WEXT, but just not implemented in cfg80211/mac80211).
      Signed-off-by: default avatarJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      faa8fdc8
  23. 29 Jan, 2009 2 commits
  24. 27 Jun, 2008 1 commit
  25. 21 May, 2008 1 commit
  26. 16 Apr, 2008 1 commit
    • Johannes Berg's avatar
      mac80211: fix key hwaccel race · 3a245766
      Johannes Berg authored
      
      
      The previous key locking patch left a small race: it would be possible
      to add a key and take the interface down before the key todo is run so
      that hwaccel for that key is enabled on an interface that is down. Avoid
      this by running the todo list when an interface is brought up or down.
      
      This patch also fixes a small bug: before this change, a few functions
      used the key list without the lock that protects it.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      3a245766
  27. 08 Apr, 2008 3 commits
    • Johannes Berg's avatar
      mac80211: fix key debugfs default_key link · d9c58f30
      Johannes Berg authored
      
      
      The default_key symlink points to the key index rather than
      they key counter, fix it.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      d9c58f30
    • Johannes Berg's avatar
      mac80211: rename files · 2c8dccc7
      Johannes Berg authored
      
      
      This patch renames all mac80211 files (except ieee80211_i.h) to get rid
      of the useless ieee80211_ prefix.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      2c8dccc7
    • Johannes Berg's avatar
      mac80211: fix key vs. sta locking problems · 3b96766f
      Johannes Berg authored
      
      
      Up to now, key manipulation is supposed to run under RTNL to
      avoid concurrent manipulations and also allow the set_key()
      hardware callback to sleep. This is not feasible because STA
      structs are rcu-protected and thus a lot of operations there
      cannot take the RTNL. Also, key references are rcu-protected
      so we cannot do things atomically.
      
      This patch changes key locking completely:
       * key operations are now atomic
       * hardware crypto offload is enabled and disabled from
         a workqueue, due to that key freeing is also delayed
       * debugfs code is also run from a workqueue
       * keys reference STAs (and vice versa!) so during STA
         unlink the STAs key reference is removed but not the
         keys STA reference, to avoid races key todo work is
         run before STA destruction.
       * fewer STA operations now need the RTNL which was
         required due to key operations
      
      This fixes the locking problems lockdep pointed out and also
      makes things more light-weight because the rtnl isn't required
      as much.
      
      Note that the key todo lock/key mutex are global locks, this
      is not required, of course, they could be per-hardware instead.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      3b96766f
  28. 29 Feb, 2008 1 commit
    • Johannes Berg's avatar
      mac80211: split ieee80211_key_alloc/free · db4d1169
      Johannes Berg authored
      
      
      In order to RCU-ify sta_info, we need to be able to allocate
      a key without linking it to an sdata/sta structure (because
      allocation cannot be done in an rcu critical section). This
      patch splits up ieee80211_key_alloc() and updates all users
      appropriately.
      
      While at it, this patch fixes a number of race conditions
      such as finally making key replacement atomic, unfortunately
      at the expense of more complex code.
      
      Note that this patch documents /existing/ bugs with sta info
      and key interaction, there is currently a race condition
      when a sta info is freed without holding the RTNL. This will
      finally be fixed by a followup patch.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      db4d1169
  29. 10 Oct, 2007 1 commit