1. 26 11月, 2008 13 次提交
  2. 03 11月, 2008 1 次提交
  3. 29 10月, 2008 1 次提交
  4. 06 10月, 2008 1 次提交
  5. 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
  6. 11 7月, 2008 1 次提交
  7. 22 5月, 2008 1 次提交
  8. 28 4月, 2008 1 次提交
  9. 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
  10. 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
  11. 13 4月, 2008 1 次提交
  12. 10 4月, 2008 1 次提交
  13. 25 3月, 2008 1 次提交
  14. 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
  15. 15 2月, 2008 1 次提交
  16. 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
  17. 29 1月, 2008 3 次提交
  18. 09 1月, 2008 1 次提交
  19. 26 11月, 2007 1 次提交
    • H
      [IPSEC]: Temporarily remove locks around copying of non-atomic fields · 8053fc3d
      Herbert Xu 提交于
      The change 050f009e
      
      	[IPSEC]: Lock state when copying non-atomic fields to user-space
      
      caused a regression.
      
      Ingo Molnar reports that it causes a potential dead-lock found by the
      lock validator as it tries to take x->lock within xfrm_state_lock while
      numerous other sites take the locks in opposite order.
      
      For 2.6.24, the best fix is to simply remove the added locks as that puts
      us back in the same state as we've been in for years.  For later kernels
      a proper fix would be to reverse the locking order for every xfrm state
      user such that if x->lock is taken together with xfrm_state_lock then
      it is to be taken within it.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      8053fc3d
  20. 11 10月, 2007 7 次提交
    • D
      [NET]: make netlink user -> kernel interface synchronious · cd40b7d3
      Denis V. Lunev 提交于
      This patch make processing netlink user -> kernel messages synchronious.
      This change was inspired by the talk with Alexey Kuznetsov about current
      netlink messages processing. He says that he was badly wrong when introduced 
      asynchronious user -> kernel communication.
      
      The call netlink_unicast is the only path to send message to the kernel
      netlink socket. But, unfortunately, it is also used to send data to the
      user.
      
      Before this change the user message has been attached to the socket queue
      and sk->sk_data_ready was called. The process has been blocked until all
      pending messages were processed. The bad thing is that this processing
      may occur in the arbitrary process context.
      
      This patch changes nlk->data_ready callback to get 1 skb and force packet
      processing right in the netlink_unicast.
      
      Kernel -> user path in netlink_unicast remains untouched.
      
      EINTR processing for in netlink_run_queue was changed. It forces rtnl_lock
      drop, but the process remains in the cycle until the message will be fully
      processed. So, there is no need to use this kludges now.
      Signed-off-by: NDenis V. Lunev <den@openvz.org>
      Acked-by: NAlexey Kuznetsov <kuznet@ms2.inr.ac.ru>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cd40b7d3
    • H
      [IPSEC]: Lock state when copying non-atomic fields to user-space · 050f009e
      Herbert Xu 提交于
      This patch adds locking so that when we're copying non-atomic fields such as
      life-time or coaddr to user-space we don't get a partial result.
      
      For af_key I've changed every instance of pfkey_xfrm_state2msg apart from
      expiration notification to include the keys and life-times.  This is in-line
      with XFRM behaviour.
      
      The actual cases affected are:
      
      * pfkey_getspi: No change as we don't have any keys to copy.
      * key_notify_sa:
      	+ ADD/UPD: This wouldn't work otherwise.
      	+ DEL: It can't hurt.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      050f009e
    • H
      [XFRM] user: Move attribute copying code into copy_to_user_state_extra · 68325d3b
      Herbert Xu 提交于
      Here's a good example of code duplication leading to code rot.  The
      notification patch did its own netlink message creation for xfrm states.
      It duplicated code that was already in dump_one_state.  Guess what, the
      next time (and the time after) when someone updated dump_one_state the
      notification path got zilch.
      
      This patch moves that code from dump_one_state to copy_to_user_state_extra
      and uses it in xfrm_notify_sa too.  Unfortunately whoever updates this
      still needs to update xfrm_sa_len since the notification path wants to
      know the exact size for allocation.
      
      At least I've added a comment saying so and if someone still forgest, we'll
      have a WARN_ON telling us so.
      
      I also changed the security size calculation to use xfrm_user_sec_ctx since
      that's what we actually put into the skb.  However it makes no practical
      difference since it has the same size as xfrm_sec_ctx.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      68325d3b
    • H
      [IPSEC]: Move common code into xfrm_alloc_spi · 658b219e
      Herbert Xu 提交于
      This patch moves some common code that conceptually belongs to the xfrm core
      from af_key/xfrm_user into xfrm_alloc_spi.
      
      In particular, the spin lock on the state is now taken inside xfrm_alloc_spi.
      Previously it also protected the construction of the response PF_KEY/XFRM
      messages to user-space.  This is inconsistent as other identical constructions
      are not protected by the state lock.  This is bad because they in fact should
      be protected but only in certain spots (so as not to hold the lock for too
      long which may cause packet drops).
      
      The SPI byte order conversion has also been moved.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      658b219e
    • H
      [NETLINK]: Avoid pointer in netlink_run_queue · 0cfad075
      Herbert Xu 提交于
      I was looking at Patrick's fix to inet_diag and it occured
      to me that we're using a pointer argument to return values
      unnecessarily in netlink_run_queue.  Changing it to return
      the value will allow the compiler to generate better code
      since the value won't have to be memory-backed.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0cfad075
    • E
      [NET]: Support multiple network namespaces with netlink · b4b51029
      Eric W. Biederman 提交于
      Each netlink socket will live in exactly one network namespace,
      this includes the controlling kernel sockets.
      
      This patch updates all of the existing netlink protocols
      to only support the initial network namespace.  Request
      by clients in other namespaces will get -ECONREFUSED.
      As they would if the kernel did not have the support for
      that netlink protocol compiled in.
      
      As each netlink protocol is updated to be multiple network
      namespace safe it can register multiple kernel sockets
      to acquire a presence in the rest of the network namespaces.
      
      The implementation in af_netlink is a simple filter implementation
      at hash table insertion and hash table look up time.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b4b51029
    • J
      [XFRM]: xfrm audit calls · ab5f5e8b
      Joy Latten 提交于
      This patch modifies the current ipsec audit layer
      by breaking it up into purpose driven audit calls.
      
      So far, the only audit calls made are when add/delete
      an SA/policy. It had been discussed to give each
      key manager it's own calls to do this, but I found
      there to be much redundnacy since they did the exact
      same things, except for how they got auid and sid, so I
      combined them. The below audit calls can be made by any
      key manager. Hopefully, this is ok.
      Signed-off-by: NJoy Latten <latten@austin.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ab5f5e8b