From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Mack Subject: Re: [RFC PATCH 0/5] Add eBPF hooks for cgroups Date: Mon, 22 Aug 2016 18:22:20 +0200 Message-ID: <05bfd5c4-4095-37ff-b7a6-85b8dca8ec70@zonque.org> References: <1471442448-1248-1-git-send-email-daniel@zonque.org> <20160819091941.GA2113@salvia> <20160819162158.GA25083@salvia> <20160819170739.GF29430@pox.localdomain> <20160822160610.GA32723@salvia> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: htejun@fb.com, daniel@iogearbox.net, ast@fb.com, davem@davemloft.net, kafai@fb.com, fw@strlen.de, harald@redhat.com, netdev@vger.kernel.org To: Pablo Neira Ayuso , Thomas Graf Return-path: Received: from svenfoo.org ([82.94.215.22]:57400 "EHLO mail.zonque.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752212AbcHVQWy (ORCPT ); Mon, 22 Aug 2016 12:22:54 -0400 In-Reply-To: <20160822160610.GA32723@salvia> Sender: netdev-owner@vger.kernel.org List-ID: On 08/22/2016 06:06 PM, Pablo Neira Ayuso wrote: > On Fri, Aug 19, 2016 at 07:07:39PM +0200, Thomas Graf wrote: >> You brought up multiple tables which reflect the cumulative approach. >> This sometimes works but has its issues as well. Users must be aware >> of each other and anticipate what rules other users might inject >> before or after their own tables. The very existence of firewalld which >> aims at democratizing this collaboration proves this point. > > Firewalld, was really required in the iptables predefined tables > model, in nft last time we talked about this during NFWS'15, future > plans for firewalld were not clear yet. > > Moreover, in nft, different users can indeed dump the ruleset and it > would be possible to validate if one policy is being shadowed by > another coming later on. The bpf bytecode dump cannot be taken to the > original representation. But as Thomas said - both things address different use-cases. For container setups, there is no administrator involved to use cli tools, so I don't think that's really much of an argument. >> So in that sense I would very much like for both models to be made >> available to users. nftables+cgroups for a cumulative approach as >> well as BPF+cgroups for the delegation approach. I don't see why the >> cgroups based filtering capability should not be made available to both. > > This patchset also needs an extra egress hook, not yet known where to > be placed, so two hooks in the network stacks in the end, That should be solvable, I'm sure. I can as well leave egress out for the next version so it can be added later on. > and this only works for cgroups version 2. I don't see a problem with that, as v1 and v2 hierarchies can peacefully coexist. > Last time we talked about this, main concerns were that this was too > specific, but this approach seems even more specific to me. Hmm, I disagree - bpf programs that are associated with cgroups are rather something that can be extended a lot in the future, for instance for handling port binding permissions etc. Unlike the proposed network cgroup controller with all sorts of complicated knobs to control ranges of ports etc, a bpf program that take care of that in a much more versatile way. I also strongly believe we can have both, a cgroup controller that has bpf programs for socket filtering and other things, _and_ a "post socket lookup netfilter" table type. Both will have their individual use-cases. Thanks, Daniel