Announcement

Collapse
No announcement yet.

BPFILTER Landing For Linux 4.18 For Eventually Better Firewall / Packet Filtering

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • BPFILTER Landing For Linux 4.18 For Eventually Better Firewall / Packet Filtering

    Phoronix: BPFILTER Landing For Linux 4.18 For Eventually Better Firewall / Packet Filtering

    Adding to the list of new features coming for Linux 4.18 is BPFILTER...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Will this compete in features, user-friendly and performance to alternatives like the BSD ones?

    Comment


    • #3
      Linux Socket Filter (the other name of BPF on Linux if I'm not mistaken) is already working pretty well. Not sure what the new features are, I know nothing about the BSD implementation.

      Comment


      • #4
        Originally posted by RhumArrange View Post
        Linux Socket Filter (the other name of BPF on Linux if I'm not mistaken) is already working pretty well. Not sure what the new features are, I know nothing about the BSD implementation.
        You are kind of mistaken.

        Yes the first usage of BPF in the Linux kernel is Linux Socket Filter. Those reading old documentation include some include with the Linux kernel like the above one would lead you to the mistake you just made.


        Currently BPF is its own subsystem in Linux as these days it used for tracing and a stack of other things on top of doing the Linux Socket Filter. BPF its coming the in Linux kernel JIT for anything that is not suitable to be a kernel module but still need to run fast and in kernel space.

        https://en.wikipedia.org/wiki/Nftables and X_tables(iptables) both are using virtual machines without any effective JIT. So BPFILTER should be able to be faster. Yes its funny that BPF in Linux kernel has been fairly much implemented for everything other than a complete firewall in the Linux kernel. Please note Berkeley Packet Filter the full name of BPF really does stand for a full firewall.

        Freebsd uses BPF a lot more in their firewall. BPFILTER will be closer to the freebsd one but still very different.

        Reality here it looks like with Firewall design we have gone around in a complete circle.

        Comment


        • #5
          Some info about performance here: https://www.netronome.com/blog/bpf-e...an-enterprise/

          A graph:

          Comment


          • #6
            [QUOTE=oibaf;n1027699]Some info about performance here: https://www.netronome.com/blog/bpf-e...an-enterprise/
            /QUOTE]

            It was nice to see in the video on that link that bpfilter is being built to be able to take iptable and nftables rules as well as it own. So should allow performance gains without requiring to redo stacks of stuff. Host driver boost should be helpful with firewall around virtual machines.

            Comment


            • #7
              Anyway the biggest performance benefit will probably be on dropping and maybe accepting packets with simple rules, where decision can be done on a low level on the stack. I wouldn't expect a lot of benefit where a state is needed (e.g. NAT, ESTABLISHED and so on) where most packets will actually be. In fact a early application is against DoS, here dropping a lot of packets can have a huge boost.
              The mentioned graph is indeed about dropping packet with a simple (no state) rule.

              Comment


              • #8
                Originally posted by oibaf View Post
                Anyway the biggest performance benefit will probably be on dropping and maybe accepting packets with simple rules, where decision can be done on a low level on the stack. I wouldn't expect a lot of benefit where a state is needed (e.g. NAT, ESTABLISHED and so on) where most packets will actually be. In fact a early application is against DoS, here dropping a lot of packets can have a huge boost.
                The mentioned graph is indeed about dropping packet with a simple (no state) rule.
                Hardware on network cards some of it is can manage state as well. So nat processing does not have to come to primary cpu some network cards are more than able todo it. Even so using a JIT over a byte code VM is going to provide a performance boost in most cases.

                Comment

                Working...
                X