1. 12 8月, 2016 2 次提交
  2. 01 7月, 2016 1 次提交
  3. 08 2月, 2016 1 次提交
    • A
      netfilter: tee: select NF_DUP_IPV6 unconditionally · 08a7f5d3
      Arnd Bergmann 提交于
      The NETFILTER_XT_TARGET_TEE option selects NF_DUP_IPV6 whenever
      IP6_NF_IPTABLES is enabled, and it ensures that it cannot be
      builtin itself if NF_CONNTRACK is a loadable module, as that
      is a dependency for NF_DUP_IPV6.
      
      However, NF_DUP_IPV6 can be enabled even if IP6_NF_IPTABLES is
      turned off, and it only really depends on IPV6. With the current
      check in tee_tg6, we call nf_dup_ipv6() whenever NF_DUP_IPV6
      is enabled. This can however be a loadable module which is
      unreachable from a built-in xt_TEE:
      
      net/built-in.o: In function `tee_tg6':
      :(.text+0x67728): undefined reference to `nf_dup_ipv6'
      
      The bug was originally introduced in the split of the xt_TEE module
      into separate modules for ipv4 and ipv6, and two patches tried
      to fix it unsuccessfully afterwards.
      
      This is a revert of the the first incorrect attempt to fix it,
      going back to depending on IPV6 as the dependency, and we
      adapt the 'select' condition accordingly.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Fixes: bbde9fc1 ("netfilter: factor out packet duplication for IPv4/IPv6")
      Fixes: 116984a3 ("netfilter: xt_TEE: use IS_ENABLED(CONFIG_NF_DUP_IPV6)")
      Fixes: 74ec4d55 ("netfilter: fix xt_TEE and xt_TPROXY dependencies")
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      08a7f5d3
  4. 05 1月, 2016 1 次提交
  5. 04 1月, 2016 1 次提交
  6. 11 11月, 2015 1 次提交
    • A
      netfilter: fix xt_TEE and xt_TPROXY dependencies · 74ec4d55
      Arnd Bergmann 提交于
      Kconfig is too smart for its own good: a Kconfig line that states
      
      	select NF_DEFRAG_IPV6 if IP6_NF_IPTABLES
      
      means that if IP6_NF_IPTABLES is set to 'm', then NF_DEFRAG_IPV6 will
      also be set to 'm', regardless of the state of the symbol from which
      it is selected. When the xt_TEE driver is built-in and nothing else
      forces NF_DEFRAG_IPV6 to be built-in, this causes a link-time error:
      
      net/built-in.o: In function `tee_tg6':
      net/netfilter/xt_TEE.c:46: undefined reference to `nf_dup_ipv6'
      
      This works around that behavior by changing the dependency to
      'if IP6_NF_IPTABLES != n', which is interpreted as boolean expression
      rather than a tristate and causes the NF_DEFRAG_IPV6 symbol to
      be built-in as well.
      
      The bug only occurs once in thousands of 'randconfig' builds and
      does not really impact real users. From inspecting the other
      surrounding Kconfig symbols, I am guessing that NETFILTER_XT_TARGET_TPROXY
      and NETFILTER_XT_MATCH_SOCKET have the same issue. If not, this
      change should still be harmless.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      74ec4d55
  7. 05 10月, 2015 2 次提交
  8. 07 8月, 2015 1 次提交
  9. 15 6月, 2015 1 次提交
  10. 27 5月, 2015 2 次提交
  11. 16 5月, 2015 1 次提交
  12. 14 5月, 2015 1 次提交
    • P
      netfilter: add netfilter ingress hook after handle_ing() under unique static key · e687ad60
      Pablo Neira 提交于
      This patch adds the Netfilter ingress hook just after the existing tc ingress
      hook, that seems to be the consensus solution for this.
      
      Note that the Netfilter hook resides under the global static key that enables
      ingress filtering. Nonetheless, Netfilter still also has its own static key for
      minimal impact on the existing handle_ing().
      
      * Without this patch:
      
      Result: OK: 6216490(c6216338+d152) usec, 100000000 (60byte,0frags)
        16086246pps 7721Mb/sec (7721398080bps) errors: 100000000
      
          42.46%  kpktgend_0   [kernel.kallsyms]   [k] __netif_receive_skb_core
          25.92%  kpktgend_0   [kernel.kallsyms]   [k] kfree_skb
           7.81%  kpktgend_0   [pktgen]            [k] pktgen_thread_worker
           5.62%  kpktgend_0   [kernel.kallsyms]   [k] ip_rcv
           2.70%  kpktgend_0   [kernel.kallsyms]   [k] netif_receive_skb_internal
           2.34%  kpktgend_0   [kernel.kallsyms]   [k] netif_receive_skb_sk
           1.44%  kpktgend_0   [kernel.kallsyms]   [k] __build_skb
      
      * With this patch:
      
      Result: OK: 6214833(c6214731+d101) usec, 100000000 (60byte,0frags)
        16090536pps 7723Mb/sec (7723457280bps) errors: 100000000
      
          41.23%  kpktgend_0      [kernel.kallsyms]  [k] __netif_receive_skb_core
          26.57%  kpktgend_0      [kernel.kallsyms]  [k] kfree_skb
           7.72%  kpktgend_0      [pktgen]           [k] pktgen_thread_worker
           5.55%  kpktgend_0      [kernel.kallsyms]  [k] ip_rcv
           2.78%  kpktgend_0      [kernel.kallsyms]  [k] netif_receive_skb_internal
           2.06%  kpktgend_0      [kernel.kallsyms]  [k] netif_receive_skb_sk
           1.43%  kpktgend_0      [kernel.kallsyms]  [k] __build_skb
      
      * Without this patch + tc ingress:
      
              tc filter add dev eth4 parent ffff: protocol ip prio 1 \
                      u32 match ip dst 4.3.2.1/32
      
      Result: OK: 9269001(c9268821+d179) usec, 100000000 (60byte,0frags)
        10788648pps 5178Mb/sec (5178551040bps) errors: 100000000
      
          40.99%  kpktgend_0   [kernel.kallsyms]  [k] __netif_receive_skb_core
          17.50%  kpktgend_0   [kernel.kallsyms]  [k] kfree_skb
          11.77%  kpktgend_0   [cls_u32]          [k] u32_classify
           5.62%  kpktgend_0   [kernel.kallsyms]  [k] tc_classify_compat
           5.18%  kpktgend_0   [pktgen]           [k] pktgen_thread_worker
           3.23%  kpktgend_0   [kernel.kallsyms]  [k] tc_classify
           2.97%  kpktgend_0   [kernel.kallsyms]  [k] ip_rcv
           1.83%  kpktgend_0   [kernel.kallsyms]  [k] netif_receive_skb_internal
           1.50%  kpktgend_0   [kernel.kallsyms]  [k] netif_receive_skb_sk
           0.99%  kpktgend_0   [kernel.kallsyms]  [k] __build_skb
      
      * With this patch + tc ingress:
      
              tc filter add dev eth4 parent ffff: protocol ip prio 1 \
                      u32 match ip dst 4.3.2.1/32
      
      Result: OK: 9308218(c9308091+d126) usec, 100000000 (60byte,0frags)
        10743194pps 5156Mb/sec (5156733120bps) errors: 100000000
      
          42.01%  kpktgend_0   [kernel.kallsyms]   [k] __netif_receive_skb_core
          17.78%  kpktgend_0   [kernel.kallsyms]   [k] kfree_skb
          11.70%  kpktgend_0   [cls_u32]           [k] u32_classify
           5.46%  kpktgend_0   [kernel.kallsyms]   [k] tc_classify_compat
           5.16%  kpktgend_0   [pktgen]            [k] pktgen_thread_worker
           2.98%  kpktgend_0   [kernel.kallsyms]   [k] ip_rcv
           2.84%  kpktgend_0   [kernel.kallsyms]   [k] tc_classify
           1.96%  kpktgend_0   [kernel.kallsyms]   [k] netif_receive_skb_internal
           1.57%  kpktgend_0   [kernel.kallsyms]   [k] netif_receive_skb_sk
      
      Note that the results are very similar before and after.
      
      I can see gcc gets the code under the ingress static key out of the hot path.
      Then, on that cold branch, it generates the code to accomodate the netfilter
      ingress static key. My explanation for this is that this reduces the pressure
      on the instruction cache for non-users as the new code is out of the hot path,
      and it comes with minimal impact for tc ingress users.
      
      Using gcc version 4.8.4 on:
      
      Architecture:          x86_64
      CPU op-mode(s):        32-bit, 64-bit
      Byte Order:            Little Endian
      CPU(s):                8
      [...]
      L1d cache:             16K
      L1i cache:             64K
      L2 cache:              2048K
      L3 cache:              8192K
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Acked-by: NAlexei Starovoitov <ast@plumgrid.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e687ad60
  13. 25 3月, 2015 1 次提交
  14. 06 3月, 2015 1 次提交
  15. 11 2月, 2015 1 次提交
  16. 27 11月, 2014 1 次提交
  17. 12 11月, 2014 1 次提交
  18. 28 10月, 2014 3 次提交
  19. 09 9月, 2014 1 次提交
  20. 07 9月, 2014 1 次提交
  21. 06 9月, 2014 1 次提交
  22. 01 9月, 2014 1 次提交
  23. 20 8月, 2014 1 次提交
  24. 29 6月, 2014 1 次提交
  25. 27 6月, 2014 1 次提交
    • P
      netfilter: log: split family specific code to nf_log_{ip,ip6,common}.c files · 83e96d44
      Pablo Neira Ayuso 提交于
      The plain text logging is currently embedded into the xt_LOG target.
      In order to be able to use the plain text logging from nft_log, as a
      first step, this patch moves the family specific code to the following
      files and Kconfig symbols:
      
      1) net/ipv4/netfilter/nf_log_ip.c: CONFIG_NF_LOG_IPV4
      2) net/ipv6/netfilter/nf_log_ip6.c: CONFIG_NF_LOG_IPV6
      3) net/netfilter/nf_log_common.c: CONFIG_NF_LOG_COMMON
      
      These new modules will be required by xt_LOG and nft_log. This patch
      is based on original patch from Arturo Borrero Gonzalez.
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      83e96d44
  26. 06 2月, 2014 2 次提交
  27. 14 1月, 2014 1 次提交
    • P
      netfilter: Add dependency on IPV6 for NF_TABLES_INET · 419331d8
      Paul Gortmaker 提交于
      Commit 1d49144c ("netfilter: nf_tables: add "inet" table for
      IPv4/IPv6") allows creation of non-IPV6 enabled .config files that
      will fail to configure/link as follows:
      
      warning: (NF_TABLES_INET) selects NF_TABLES_IPV6 which has unmet direct dependencies (NET && INET && IPV6 && NETFILTER && NF_TABLES)
      warning: (NF_TABLES_INET) selects NF_TABLES_IPV6 which has unmet direct dependencies (NET && INET && IPV6 && NETFILTER && NF_TABLES)
      warning: (NF_TABLES_INET) selects NF_TABLES_IPV6 which has unmet direct dependencies (NET && INET && IPV6 && NETFILTER && NF_TABLES)
      net/built-in.o: In function `nft_reject_eval':
      nft_reject.c:(.text+0x651e8): undefined reference to `nf_ip6_checksum'
      nft_reject.c:(.text+0x65270): undefined reference to `ip6_route_output'
      nft_reject.c:(.text+0x656c4): undefined reference to `ip6_dst_hoplimit'
      make: *** [vmlinux] Error 1
      
      Since the feature is to allow for a mixed IPV4 and IPV6 table, it
      seems sensible to make it depend on IPV6.
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      Acked-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      419331d8
  28. 10 1月, 2014 1 次提交
    • J
      netfilter: introduce l2tp match extension · 74f77a6b
      James Chapman 提交于
      Introduce an xtables add-on for matching L2TP packets. Supports L2TPv2
      and L2TPv3 over IPv4 and IPv6. As well as filtering on L2TP tunnel-id
      and session-id, the filtering decision can also include the L2TP
      packet type (control or data), protocol version (2 or 3) and
      encapsulation type (UDP or IP).
      
      The most common use for this will likely be to filter L2TP data
      packets of individual L2TP tunnels or sessions. While a u32 match can
      be used, the L2TP protocol headers are such that field offsets differ
      depending on bits set in the header, making rules for matching generic
      L2TP connections cumbersome. This match extension takes care of all
      that.
      Signed-off-by: NJames Chapman <jchapman@katalix.com>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      74f77a6b
  29. 08 1月, 2014 1 次提交
  30. 04 1月, 2014 1 次提交
    • D
      netfilter: x_tables: lightweight process control group matching · 82a37132
      Daniel Borkmann 提交于
      It would be useful e.g. in a server or desktop environment to have
      a facility in the notion of fine-grained "per application" or "per
      application group" firewall policies. Probably, users in the mobile,
      embedded area (e.g. Android based) with different security policy
      requirements for application groups could have great benefit from
      that as well. For example, with a little bit of configuration effort,
      an admin could whitelist well-known applications, and thus block
      otherwise unwanted "hard-to-track" applications like [1] from a
      user's machine. Blocking is just one example, but it is not limited
      to that, meaning we can have much different scenarios/policies that
      netfilter allows us than just blocking, e.g. fine grained settings
      where applications are allowed to connect/send traffic to, application
      traffic marking/conntracking, application-specific packet mangling,
      and so on.
      
      Implementation of PID-based matching would not be appropriate
      as they frequently change, and child tracking would make that
      even more complex and ugly. Cgroups would be a perfect candidate
      for accomplishing that as they associate a set of tasks with a
      set of parameters for one or more subsystems, in our case the
      netfilter subsystem, which, of course, can be combined with other
      cgroup subsystems into something more complex if needed.
      
      As mentioned, to overcome this constraint, such processes could
      be placed into one or multiple cgroups where different fine-grained
      rules can be defined depending on the application scenario, while
      e.g. everything else that is not part of that could be dropped (or
      vice versa), thus making life harder for unwanted processes to
      communicate to the outside world. So, we make use of cgroups here
      to track jobs and limit their resources in terms of iptables
      policies; in other words, limiting, tracking, etc what they are
      allowed to communicate.
      
      In our case we're working on outgoing traffic based on which local
      socket that originated from. Also, one doesn't even need to have
      an a-prio knowledge of the application internals regarding their
      particular use of ports or protocols. Matching is *extremly*
      lightweight as we just test for the sk_classid marker of sockets,
      originating from net_cls. net_cls and netfilter do not contradict
      each other; in fact, each construct can live as standalone or they
      can be used in combination with each other, which is perfectly fine,
      plus it serves Tejun's requirement to not introduce a new cgroups
      subsystem. Through this, we result in a very minimal and efficient
      module, and don't add anything except netfilter code.
      
      One possible, minimal usage example (many other iptables options
      can be applied obviously):
      
       1) Configuring cgroups if not already done, e.g.:
      
        mkdir /sys/fs/cgroup/net_cls
        mount -t cgroup -o net_cls net_cls /sys/fs/cgroup/net_cls
        mkdir /sys/fs/cgroup/net_cls/0
        echo 1 > /sys/fs/cgroup/net_cls/0/net_cls.classid
        (resp. a real flow handle id for tc)
      
       2) Configuring netfilter (iptables-nftables), e.g.:
      
        iptables -A OUTPUT -m cgroup ! --cgroup 1 -j DROP
      
       3) Running applications, e.g.:
      
        ping 208.67.222.222  <pid:1799>
        echo 1799 > /sys/fs/cgroup/net_cls/0/tasks
        64 bytes from 208.67.222.222: icmp_seq=44 ttl=49 time=11.9 ms
        [...]
        ping 208.67.220.220  <pid:1804>
        ping: sendmsg: Operation not permitted
        [...]
        echo 1804 > /sys/fs/cgroup/net_cls/0/tasks
        64 bytes from 208.67.220.220: icmp_seq=89 ttl=56 time=19.0 ms
        [...]
      
      Of course, real-world deployments would make use of cgroups user
      space toolsuite, or own custom policy daemons dynamically moving
      applications from/to various cgroups.
      
        [1] http://www.blackhat.com/presentations/bh-europe-06/bh-eu-06-biondi/bh-eu-06-biondi-up.pdfSigned-off-by: NDaniel Borkmann <dborkman@redhat.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: cgroups@vger.kernel.org
      Acked-by: NLi Zefan <lizefan@huawei.com>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      82a37132
  31. 02 1月, 2014 1 次提交
  32. 31 12月, 2013 1 次提交
    • E
      netfilter: nft_reject: support for IPv6 and TCP reset · bee11dc7
      Eric Leblond 提交于
      This patch moves nft_reject_ipv4 to nft_reject and adds support
      for IPv6 protocol. This patch uses functions included in nf_reject.h
      to implement reject by TCP reset.
      
      The code has to be build as a module if NF_TABLES_IPV6 is also a
      module to avoid compilation error due to usage of IPv6 functions.
      This has been done in Kconfig by using the construct:
      
       depends on NF_TABLES_IPV6 || !NF_TABLES_IPV6
      
      This seems a bit weird in terms of syntax but works perfectly.
      Signed-off-by: NEric Leblond <eric@regit.org>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      bee11dc7
  33. 29 12月, 2013 1 次提交
    • E
      netfilter: select NFNETLINK when enabling NF_TABLES · 5f291c28
      Eric Leblond 提交于
      In Kconfig, nf_tables depends on NFNETLINK so building nf_tables as
      a module or inside kernel depends on the state of NFNETLINK inside
      the kernel config. If someone wants to build nf_tables inside the
      kernel, it is necessary to also build NFNETLINK inside the kernel.
      But NFNETLINK can not be set in the menu so it is necessary to
      toggle other nfnetlink subsystems such as logging and nfacct to see
      the nf_tables switch.
      
      This patch changes the dependency from 'depend' to 'select' inside
      Kconfig to allow to set the build of nftables as modules or inside
      kernel independently.
      Signed-off-by: NEric Leblond <eric@regit.org>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      5f291c28
  34. 24 12月, 2013 1 次提交