1. 08 7月, 2011 3 次提交
    • J
      mac80211: fix CMAC races · 75396ae6
      Johannes Berg 提交于
      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: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      75396ae6
    • J
      mac80211: fix CCMP races · aba83a0b
      Johannes Berg 提交于
      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: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      aba83a0b
    • J
      mac80211: fix TKIP races, make API easier to use · 523b02ea
      Johannes Berg 提交于
      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: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      523b02ea
  2. 07 7月, 2011 3 次提交
  3. 06 7月, 2011 8 次提交
  4. 30 6月, 2011 1 次提交
  5. 28 6月, 2011 7 次提交
  6. 25 6月, 2011 1 次提交
  7. 23 6月, 2011 2 次提交
    • J
      nl80211: use netlink consistent dump feature for BSS dumps · 9720bb3a
      Johannes Berg 提交于
      Use the new consistent dump feature from (generic) netlink
      to advertise when dumps are incomplete.
      
      Readers may note that this does not initialize the
      rdev->bss_generation counter to a non-zero value. This is
      still OK since the value is modified only under spinlock
      when the list is modified. Since the dump code holds the
      spinlock, the value will either be > 0 already, or the
      list will still be empty in which case a consistent dump
      will actually be made (and be empty).
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      9720bb3a
    • J
      netlink: advertise incomplete dumps · 670dc283
      Johannes Berg 提交于
      Consider the following situation:
       * a dump that would show 8 entries, four in the first
         round, and four in the second
       * between the first and second rounds, 6 entries are
         removed
       * now the second round will not show any entry, and
         even if there is a sequence/generation counter the
         application will not know
      
      To solve this problem, add a new flag NLM_F_DUMP_INTR
      to the netlink header that indicates the dump wasn't
      consistent, this flag can also be set on the MSG_DONE
      message that terminates the dump, and as such above
      situation can be detected.
      
      To achieve this, add a sequence counter to the netlink
      callback struct. Of course, netlink code still needs
      to use this new functionality. The correct way to do
      that is to always set cb->seq when a dumpit callback
      is invoked and call nl_dump_check_consistent() for
      each new message. The core code will also call this
      function for the final MSG_DONE message.
      
      To make it usable with generic netlink, a new function
      genlmsg_nlhdr() is needed to obtain the netlink header
      from the genetlink user header.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      670dc283
  8. 22 6月, 2011 1 次提交
  9. 21 6月, 2011 3 次提交
  10. 18 6月, 2011 3 次提交
  11. 17 6月, 2011 4 次提交
  12. 16 6月, 2011 1 次提交
  13. 15 6月, 2011 3 次提交