1. 03 Nov, 2017 4 commits
    • Egil Hjelmeland's avatar
      net: Define eth_stp_addr in linux/etherdevice.h · 05428729
      Egil Hjelmeland authored
      The lan9303 driver defines eth_stp_addr as a synonym to
      eth_reserved_addr_base to get the STP ethernet address 01:80:c2:00:00:00.
      
      eth_reserved_addr_base is also used to define the start of Bridge Reserved
      ethernet address range, which happen to be the STP address.
      
      br_dev_setup refer to eth_reserved_addr_base as a definition of STP
      address.
      
      Clean up by:
       - Move the eth_stp_addr definition to linux/etherdevice.h
       - Use eth_stp_addr instead of eth_reserved_addr_base in br_dev_setup.
      Signed-off-by: default avatarEgil Hjelmeland <privat@egil-hjelmeland.no>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      05428729
    • Felix Manlunas's avatar
    • Song Liu's avatar
      tcp: add tracepoint trace_tcp_retransmit_synack() · cf34ce3d
      Song Liu authored
      This tracepoint can be used to trace synack retransmits. It maintains
      pointer to struct request_sock.
      
      We cannot simply reuse trace_tcp_retransmit_skb() here, because the
      sk here is the LISTEN socket. The IP addresses and ports should be
      extracted from struct request_sock.
      
      Note that, like many other tracepoints, this patch uses IS_ENABLED
      in TP_fast_assign macro, which triggers sparse warning like:
      
      ./include/trace/events/tcp.h:274:1: error: directive in argument list
      ./include/trace/events/tcp.h:281:1: error: directive in argument list
      
      However, there is no good solution to avoid these warnings. To the
      best of our knowledge, these warnings are harmless.
      Signed-off-by: default avatarSong Liu <songliubraving@fb.com>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Acked-by: default avatarMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cf34ce3d
    • Tom Herbert's avatar
      ipv6: Implement limits on Hop-by-Hop and Destination options · 47d3d7ac
      Tom Herbert authored
      RFC 8200 (IPv6) defines Hop-by-Hop options and Destination options
      extension headers. Both of these carry a list of TLVs which is
      only limited by the maximum length of the extension header (2048
      bytes). By the spec a host must process all the TLVs in these
      options, however these could be used as a fairly obvious
      denial of service attack. I think this could in fact be
      a significant DOS vector on the Internet, one mitigating
      factor might be that many FWs drop all packets with EH (and
      obviously this is only IPv6) so an Internet wide attack might not
      be so effective (yet!).
      
      By my calculation, the worse case packet with TLVs in a standard
      1500 byte MTU packet that would be processed by the stack contains
      1282 invidual TLVs (including pad TLVS) or 724 two byte TLVs. I
      wrote a quick test program that floods a whole bunch of these
      packets to a host and sure enough there is substantial time spent
      in ip6_parse_tlv. These packets contain nothing but unknown TLVS
      (that are ignored), TLV padding, and bogus UDP header with zero
      payload length.
      
        25.38%  [kernel]                    [k] __fib6_clean_all
        21.63%  [kernel]                    [k] ip6_parse_tlv
         4.21%  [kernel]                    [k] __local_bh_enable_ip
         2.18%  [kernel]                    [k] ip6_pol_route.isra.39
         1.98%  [kernel]                    [k] fib6_walk_continue
         1.88%  [kernel]                    [k] _raw_write_lock_bh
         1.65%  [kernel]                    [k] dst_release
      
      This patch adds configurable limits to Destination and Hop-by-Hop
      options. There are three limits that may be set:
        - Limit the number of options in a Hop-by-Hop or Destination options
          extension header.
        - Limit the byte length of a Hop-by-Hop or Destination options
          extension header.
        - Disallow unrecognized options in a Hop-by-Hop or Destination
          options extension header.
      
      The limits are set in corresponding sysctls:
      
        ipv6.sysctl.max_dst_opts_cnt
        ipv6.sysctl.max_hbh_opts_cnt
        ipv6.sysctl.max_dst_opts_len
        ipv6.sysctl.max_hbh_opts_len
      
      If a max_*_opts_cnt is less than zero then unknown TLVs are disallowed.
      The number of known TLVs that are allowed is the absolute value of
      this number.
      
      If a limit is exceeded when processing an extension header the packet is
      dropped.
      
      Default values are set to 8 for options counts, and set to INT_MAX
      for maximum length. Note the choice to limit options to 8 is an
      arbitrary guess (roughly based on the fact that the stack supports
      three HBH options and just one destination option).
      
      These limits have being proposed in draft-ietf-6man-rfc6434-bis.
      
      Tested (by Martin Lau)
      
      I tested out 1 thread (i.e. one raw_udp process).
      
      I changed the net.ipv6.max_dst_(opts|hbh)_number between 8 to 2048.
      With sysctls setting to 2048, the softirq% is packed to 100%.
      With 8, the softirq% is almost unnoticable from mpstat.
      
      v2;
        - Code and documention cleanup.
        - Change references of RFC2460 to be RFC8200.
        - Add reference to RFC6434-bis where the limits will be in standard.
      Signed-off-by: default avatarTom Herbert <tom@quantonium.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      47d3d7ac
  2. 02 Nov, 2017 36 commits