1. 16 2月, 2010 2 次提交
    • J
      xfrm: Flushing empty SPD generates false events · 0dca3a84
      jamal 提交于
      Observed similar behavior on SPD as previouly seen on SAD flushing..
      This fixes it.
      
      cheers,
      jamal
      commit 428b20432dc31bc2e01a94cd451cf5a2c00d2bf4
      Author: Jamal Hadi Salim <hadi@cyberus.ca>
      Date:   Thu Feb 11 05:49:38 2010 -0500
      
          xfrm: Flushing empty SPD generates false events
      
          To see the effect make sure you have an empty SPD.
          On window1 "ip xfrm mon" and on window2 issue "ip xfrm policy flush"
          You get prompt back in window1 and you see the flush event on window2.
          With this fix, you still get prompt on window1 but no event on window2.
      Signed-off-by: NJamal Hadi Salim <hadi@cyberus.ca>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0dca3a84
    • J
      xfrm: Flushing empty SAD generates false events · 19f4c713
      jamal 提交于
      To see the effect make sure you have an empty SAD.
      -On window1 "ip xfrm mon"
      -on window2 issue "ip xfrm state flush"
      You get prompt back in window1
      and you see the flush event on window2.
      With this fix, you still get prompt on window1 but no
      event on window2.
      
      I was tempted to return -ESRCH on window1 (which would
      show "RTNETLINK answers: No such process") but didnt want
      to change current behavior.
      
      cheers,
      jamal
      commit 5f3dd4a772326166e1bcf54acc2391df00dc7ab5
      Author: Jamal Hadi Salim <hadi@cyberus.ca>
      Date:   Thu Feb 11 04:41:36 2010 -0500
      
          xfrm: Flushing empty SAD generates false events
      
          To see the effect make sure you have an empty SAD.
          On window1 "ip xfrm mon" and on window2 issue "ip xfrm state flush"
          You get prompt back in window1 and you see the flush event on window2.
          With this fix, you still get prompt on window1 but no event on window2.
      Signed-off-by: NJamal Hadi Salim <hadi@cyberus.ca>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      19f4c713
  2. 13 2月, 2010 1 次提交
  3. 24 1月, 2010 1 次提交
  4. 04 12月, 2009 1 次提交
  5. 26 11月, 2009 1 次提交
  6. 21 1月, 2009 1 次提交
  7. 15 1月, 2009 1 次提交
  8. 15 12月, 2008 1 次提交
  9. 26 11月, 2008 14 次提交
  10. 03 11月, 2008 1 次提交
  11. 29 10月, 2008 1 次提交
  12. 06 10月, 2008 1 次提交
  13. 01 10月, 2008 1 次提交
    • H
      ipsec: Put dumpers on the dump list · 12a169e7
      Herbert Xu 提交于
      Herbert Xu came up with the idea and the original patch to make
      xfrm_state dump list contain also dumpers:
      
      As it is we go to extraordinary lengths to ensure that states
      don't go away while dumpers go to sleep.  It's much easier if
      we just put the dumpers themselves on the list since they can't
      go away while they're going.
      
      I've also changed the order of addition on new states to prevent
      a never-ending dump.
      
      Timo Teräs improved the patch to apply cleanly to latest tree,
      modified iteration code to be more readable by using a common
      struct for entries in the list, implemented the same idea for
      xfrm_policy dumping and moved the af_key specific "last" entry
      caching to af_key.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NTimo Teras <timo.teras@iki.fi>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      12a169e7
  14. 11 7月, 2008 1 次提交
  15. 22 5月, 2008 1 次提交
  16. 28 4月, 2008 1 次提交
  17. 22 4月, 2008 1 次提交
    • H
      [IPSEC]: Fix catch-22 with algorithm IDs above 31 · c5d18e98
      Herbert Xu 提交于
      As it stands it's impossible to use any authentication algorithms
      with an ID above 31 portably.  It just happens to work on x86 but
      fails miserably on ppc64.
      
      The reason is that we're using a bit mask to check the algorithm
      ID but the mask is only 32 bits wide.
      
      After looking at how this is used in the field, I have concluded
      that in the long term we should phase out state matching by IDs
      because this is made superfluous by the reqid feature.  For current
      applications, the best solution IMHO is to allow all algorithms when
      the bit masks are all ~0.
      
      The following patch does exactly that.
      
      This bug was identified by IBM when testing on the ppc64 platform
      using the NULL authentication algorithm which has an ID of 251.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c5d18e98
  18. 15 4月, 2008 1 次提交
    • D
      [XFRM]: Compilation warnings in xfrm_user.c. · 2c8dd116
      Denis V. Lunev 提交于
      When CONFIG_SECURITY_NETWORK_XFRM is undefined the following warnings appears:
      net/xfrm/xfrm_user.c: In function 'xfrm_add_pol_expire':
      net/xfrm/xfrm_user.c:1576: warning: 'ctx' may be used uninitialized in this function
      net/xfrm/xfrm_user.c: In function 'xfrm_get_policy':
      net/xfrm/xfrm_user.c:1340: warning: 'ctx' may be used uninitialized in this function
      (security_xfrm_policy_alloc is noop for the case).
      
      It seems that they are result of the commit
      03e1ad7b ("LSM: Make the Labeled IPsec
      hooks more stack friendly")
      Signed-off-by: NDenis V. Lunev <den@openvz.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2c8dd116
  19. 13 4月, 2008 1 次提交
  20. 10 4月, 2008 1 次提交
  21. 25 3月, 2008 1 次提交
  22. 29 2月, 2008 1 次提交
    • T
      [XFRM]: Speed up xfrm_policy and xfrm_state walking · 4c563f76
      Timo Teras 提交于
      Change xfrm_policy and xfrm_state walking algorithm from O(n^2) to O(n).
      This is achieved adding the entries to one more list which is used
      solely for walking the entries.
      
      This also fixes some races where the dump can have duplicate or missing
      entries when the SPD/SADB is modified during an ongoing dump.
      
      Dumping SADB with 20000 entries using "time ip xfrm state" the sys
      time dropped from 1.012s to 0.080s.
      Signed-off-by: NTimo Teras <timo.teras@iki.fi>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4c563f76
  23. 15 2月, 2008 1 次提交
  24. 01 2月, 2008 1 次提交
    • H
      [IPSEC]: Add support for combined mode algorithms · 1a6509d9
      Herbert Xu 提交于
      This patch adds support for combined mode algorithms with GCM being
      the first algorithm supported.
      
      Combined mode algorithms can be added through the xfrm_user interface
      using the new algorithm payload type XFRMA_ALG_AEAD.  Each algorithms
      is identified by its name and the ICV length.
      
      For the purposes of matching algorithms in xfrm_tmpl structures,
      combined mode algorithms occupy the same name space as encryption
      algorithms.  This is in line with how they are negotiated using IKE.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1a6509d9
  25. 29 1月, 2008 2 次提交