1. 27 2月, 2009 1 次提交
  2. 26 1月, 2009 1 次提交
  3. 26 11月, 2008 14 次提交
  4. 07 11月, 2008 1 次提交
  5. 01 11月, 2008 1 次提交
    • A
      key: fix setkey(8) policy set breakage · 920da692
      Alexey Dobriyan 提交于
      Steps to reproduce:
      
      	#/usr/sbin/setkey -f
      	flush;
      	spdflush;
      
      	add 192.168.0.42 192.168.0.1 ah 24500 -A hmac-md5 "1234567890123456";
      	add 192.168.0.42 192.168.0.1 esp 24501 -E 3des-cbc "123456789012123456789012";
      
      	spdadd 192.168.0.42 192.168.0.1 any -P out ipsec
      		esp/transport//require
      		ah/transport//require;
      
      setkey: invalid keymsg length
      
      Policy dump will bail out with the same message after that.
      
      -recv(4, "\2\16\0\0\32\0\3\0\0\0\0\0\37\r\0\0\3\0\5\0\377 \0\0\2\0\0\0\300\250\0*\0"..., 32768, 0) = 208
      +recv(4, "\2\16\0\0\36\0\3\0\0\0\0\0H\t\0\0\3\0\5\0\377 \0\0\2\0\0\0\300\250\0*\0"..., 32768, 0) = 208
      Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      920da692
  6. 11 10月, 2008 1 次提交
  7. 06 10月, 2008 1 次提交
  8. 01 10月, 2008 2 次提交
  9. 26 7月, 2008 1 次提交
  10. 12 6月, 2008 4 次提交
  11. 11 6月, 2008 1 次提交
  12. 22 5月, 2008 1 次提交
  13. 28 4月, 2008 1 次提交
  14. 25 4月, 2008 1 次提交
  15. 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
  16. 13 4月, 2008 1 次提交
  17. 25 3月, 2008 1 次提交
  18. 04 3月, 2008 1 次提交
  19. 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
  20. 27 2月, 2008 1 次提交
  21. 15 2月, 2008 1 次提交
  22. 10 2月, 2008 2 次提交