1. 06 5月, 2017 1 次提交
    • E
      tcp: randomize timestamps on syncookies · 84b114b9
      Eric Dumazet 提交于
      Whole point of randomization was to hide server uptime, but an attacker
      can simply start a syn flood and TCP generates 'old style' timestamps,
      directly revealing server jiffies value.
      
      Also, TSval sent by the server to a particular remote address vary
      depending on syncookies being sent or not, potentially triggering PAWS
      drops for innocent clients.
      
      Lets implement proper randomization, including for SYNcookies.
      
      Also we do not need to export sysctl_tcp_timestamps, since it is not
      used from a module.
      
      In v2, I added Florian feedback and contribution, adding tsoff to
      tcp_get_cookie_sock().
      
      v3 removed one unused variable in tcp_v4_connect() as Florian spotted.
      
      Fixes: 95a22cae ("tcp: randomize tcp timestamp offsets for each connection")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reviewed-by: NFlorian Westphal <fw@strlen.de>
      Tested-by: NFlorian Westphal <fw@strlen.de>
      Cc: Yuchung Cheng <ycheng@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      84b114b9
  2. 25 3月, 2017 1 次提交
  3. 10 3月, 2017 1 次提交
  4. 13 1月, 2017 1 次提交
    • E
      secure_seq: fix sparse errors · c1ce1560
      Eric Dumazet 提交于
      Fixes following warnings :
      
      net/core/secure_seq.c:125:28: warning: incorrect type in argument 1
      (different base types)
      net/core/secure_seq.c:125:28:    expected unsigned int const [unsigned]
      [usertype] a
      net/core/secure_seq.c:125:28:    got restricted __be32 [usertype] saddr
      net/core/secure_seq.c:125:35: warning: incorrect type in argument 2
      (different base types)
      net/core/secure_seq.c:125:35:    expected unsigned int const [unsigned]
      [usertype] b
      net/core/secure_seq.c:125:35:    got restricted __be32 [usertype] daddr
      net/core/secure_seq.c:125:43: warning: cast from restricted __be16
      net/core/secure_seq.c:125:61: warning: restricted __be16 degrades to
      integer
      
      Fixes: 7cd23e53 ("secure_seq: use SipHash in place of MD5")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reviewed-by: NJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c1ce1560
  5. 10 1月, 2017 1 次提交
    • J
      secure_seq: use SipHash in place of MD5 · 7cd23e53
      Jason A. Donenfeld 提交于
      This gives a clear speed and security improvement. Siphash is both
      faster and is more solid crypto than the aging MD5.
      
      Rather than manually filling MD5 buffers, for IPv6, we simply create
      a layout by a simple anonymous struct, for which gcc generates
      rather efficient code. For IPv4, we pass the values directly to the
      short input convenience functions.
      
      64-bit x86_64:
      [    1.683628] secure_tcpv6_sequence_number_md5# cycles: 99563527
      [    1.717350] secure_tcp_sequence_number_md5# cycles: 92890502
      [    1.741968] secure_tcpv6_sequence_number_siphash# cycles: 67825362
      [    1.762048] secure_tcp_sequence_number_siphash# cycles: 67485526
      
      32-bit x86:
      [    1.600012] secure_tcpv6_sequence_number_md5# cycles: 103227892
      [    1.634219] secure_tcp_sequence_number_md5# cycles: 94732544
      [    1.669102] secure_tcpv6_sequence_number_siphash# cycles: 96299384
      [    1.700165] secure_tcp_sequence_number_siphash# cycles: 86015473
      Signed-off-by: NJason A. Donenfeld <Jason@zx2c4.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: David Miller <davem@davemloft.net>
      Cc: David Laight <David.Laight@aculab.com>
      Cc: Tom Herbert <tom@herbertland.com>
      Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7cd23e53
  6. 03 12月, 2016 2 次提交
  7. 26 5月, 2015 1 次提交
  8. 23 8月, 2014 1 次提交
  9. 03 6月, 2014 1 次提交
    • E
      inetpeer: get rid of ip_id_count · 73f156a6
      Eric Dumazet 提交于
      Ideally, we would need to generate IP ID using a per destination IP
      generator.
      
      linux kernels used inet_peer cache for this purpose, but this had a huge
      cost on servers disabling MTU discovery.
      
      1) each inet_peer struct consumes 192 bytes
      
      2) inetpeer cache uses a binary tree of inet_peer structs,
         with a nominal size of ~66000 elements under load.
      
      3) lookups in this tree are hitting a lot of cache lines, as tree depth
         is about 20.
      
      4) If server deals with many tcp flows, we have a high probability of
         not finding the inet_peer, allocating a fresh one, inserting it in
         the tree with same initial ip_id_count, (cf secure_ip_id())
      
      5) We garbage collect inet_peer aggressively.
      
      IP ID generation do not have to be 'perfect'
      
      Goal is trying to avoid duplicates in a short period of time,
      so that reassembly units have a chance to complete reassembly of
      fragments belonging to one message before receiving other fragments
      with a recycled ID.
      
      We simply use an array of generators, and a Jenkin hash using the dst IP
      as a key.
      
      ipv6_select_ident() is put back into net/ipv6/ip6_output.c where it
      belongs (it is only used from this file)
      
      secure_ip_id() and secure_ipv6_id() no longer are needed.
      
      Rename ip_select_ident_more() to ip_select_ident_segs() to avoid
      unnecessary decrement/increment of the number of segments.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      73f156a6
  10. 24 10月, 2013 1 次提交
  11. 20 10月, 2013 1 次提交
  12. 10 10月, 2013 1 次提交
    • F
      net: secure_seq: Fix warning when CONFIG_IPV6 and CONFIG_INET are not selected · cb03db9d
      Fabio Estevam 提交于
      net_secret() is only used when CONFIG_IPV6 or CONFIG_INET are selected.
      
      Building a defconfig with both of these symbols unselected (Using the ARM
      at91sam9rl_defconfig, for example) leads to the following build warning:
      
      $ make at91sam9rl_defconfig
      #
      # configuration written to .config
      #
      
      $ make net/core/secure_seq.o
      scripts/kconfig/conf --silentoldconfig Kconfig
        CHK     include/config/kernel.release
        CHK     include/generated/uapi/linux/version.h
        CHK     include/generated/utsrelease.h
      make[1]: `include/generated/mach-types.h' is up to date.
        CALL    scripts/checksyscalls.sh
        CC      net/core/secure_seq.o
      net/core/secure_seq.c:17:13: warning: 'net_secret_init' defined but not used [-Wunused-function]
      
      Fix this warning by protecting the definition of net_secret() with these
      symbols.
      Reported-by: NOlof Johansson <olof@lixom.net>
      Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cb03db9d
  13. 29 9月, 2013 1 次提交
  14. 30 4月, 2013 1 次提交
  15. 30 8月, 2012 1 次提交
  16. 17 1月, 2012 1 次提交
  17. 17 12月, 2011 1 次提交
  18. 12 12月, 2011 1 次提交
  19. 07 12月, 2011 1 次提交
  20. 21 10月, 2011 1 次提交
  21. 07 8月, 2011 1 次提交
    • D
      net: Compute protocol sequence numbers and fragment IDs using MD5. · 6e5714ea
      David S. Miller 提交于
      Computers have become a lot faster since we compromised on the
      partial MD4 hash which we use currently for performance reasons.
      
      MD5 is a much safer choice, and is inline with both RFC1948 and
      other ISS generators (OpenBSD, Solaris, etc.)
      
      Furthermore, only having 24-bits of the sequence number be truly
      unpredictable is a very serious limitation.  So the periodic
      regeneration and 8-bit counter have been removed.  We compute and
      use a full 32-bit sequence number.
      
      For ipv6, DCCP was found to use a 32-bit truncated initial sequence
      number (it needs 43-bits) and that is fixed here as well.
      Reported-by: NDan Kaminsky <dan@doxpara.com>
      Tested-by: NWilly Tarreau <w@1wt.eu>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6e5714ea