[resend as plaintext, apparently mobile gmail will send HTML mails]
On Thu, Feb 22, 2018 at 3:20 AM, Alexei Starovoitov
wrote:
> On Wed, Feb 21, 2018 at 01:13:03PM +0100, Florian Westphal wrote:
>>
>> Obvious candidates are: meta, numgen, limit, objref, quota, reject.
>>
>> We should probably als
On Thu, Feb 22, 2018 at 12:39:15PM +0100, Pablo Neira Ayuso wrote:
> Hi Alexei,
>
> On Wed, Feb 21, 2018 at 06:20:37PM -0800, Alexei Starovoitov wrote:
> > On Wed, Feb 21, 2018 at 01:13:03PM +0100, Florian Westphal wrote:
> > >
> > > Obvious candidates are: meta, numgen, limit, objref, quota, rej
Hi Alexei,
On Wed, Feb 21, 2018 at 06:20:37PM -0800, Alexei Starovoitov wrote:
> On Wed, Feb 21, 2018 at 01:13:03PM +0100, Florian Westphal wrote:
> >
> > Obvious candidates are: meta, numgen, limit, objref, quota, reject.
> >
> > We should probably also consider removing
> > CONFIG_NFT_SET_RBTR
On Wed, Feb 21, 2018 at 01:13:03PM +0100, Florian Westphal wrote:
>
> Obvious candidates are: meta, numgen, limit, objref, quota, reject.
>
> We should probably also consider removing
> CONFIG_NFT_SET_RBTREE and CONFIG_NFT_SET_HASH and just always
> build both too (at least rbtree since that offe
Pablo Neira Ayuso wrote:
> On Tue, Feb 20, 2018 at 05:52:54PM -0800, Alexei Starovoitov wrote:
> > On Tue, Feb 20, 2018 at 11:44:31AM +0100, Pablo Neira Ayuso wrote:
> > >
> > > Don't get me wrong, no software is safe from security issues, but if you
> > > don't abstract your resources in the
On Tue, Feb 20, 2018 at 05:52:54PM -0800, Alexei Starovoitov wrote:
> On Tue, Feb 20, 2018 at 11:44:31AM +0100, Pablo Neira Ayuso wrote:
> >
> > Don't get me wrong, no software is safe from security issues, but if you
> > don't abstract your resources in the right way, you have more chance to
On Tue, Feb 20, 2018 at 11:44:31AM +0100, Pablo Neira Ayuso wrote:
>
> Don't get me wrong, no software is safe from security issues, but if you
> don't abstract your resources in the right way, you have more chance to
> have experimence more problems.
interesting point.
The key part of ipta
Hi Michal,
On Tue, Feb 20, 2018 at 10:35:41AM +0100, Michal Kubecek wrote:
> On Mon, Feb 19, 2018 at 06:09:39PM +0100, Phil Sutter wrote:
> > What puzzles me about your argumentation is that you seem to propose for
> > the kernel to cover up flaws in userspace. Spinning this concept further
> > wo
From: Pablo Neira Ayuso
Date: Tue, 20 Feb 2018 11:44:31 +0100
> * Lack of sufficient abstraction: bpf is not only exposing its own
> software bugs through its interface, but it will also bite the dust
> with CPU bugs due to lack of glue code to hide details behind the
> syscall interface cu
On 02/20/2018 11:44 AM, Pablo Neira Ayuso wrote:
> Hi David!
>
> On Mon, Feb 19, 2018 at 12:22:26PM -0500, David Miller wrote:
> [...]
>> Netfilter's chronic performance differential is why a lot of mindshare
>> was lost to userspace networking technologies.
>
> Claiming that Netfilter is the rea
Hi David,
On Mon, Feb 19, 2018 at 12:15:37PM -0500, David Miller wrote:
> From: Phil Sutter
> Date: Mon, 19 Feb 2018 18:09:39 +0100
>
> > What puzzles me about your argumentation is that you seem to propose for
> > the kernel to cover up flaws in userspace. Spinning this concept further
> > woul
Hi David!
On Mon, Feb 19, 2018 at 12:22:26PM -0500, David Miller wrote:
[...]
> Netfilter's chronic performance differential is why a lot of mindshare
> was lost to userspace networking technologies.
Claiming that Netfilter is the reason for the massive adoption of
userspace networking isn't a fa
On Mon, Feb 19, 2018 at 06:09:39PM +0100, Phil Sutter wrote:
> What puzzles me about your argumentation is that you seem to propose for
> the kernel to cover up flaws in userspace. Spinning this concept further
> would mean that if there would be an old bug in iproute2 we should think
> of adding a
> I see several possible areas of contention:
>
> 1) If you aim for a non-feature-complete support of iptables rules, it
>will create confusion to the users.
Right, you need full feature parity to be avoid ending up having to
maintain two implementations.
It seems uncontroversial that BPF can
Hi David,
On Mon, 19 Feb 2018, Florian Westphal wrote:
> David Miller wrote:
> >
> > Florian, first of all, the whole "change the iptables binary" idea is
> > a non-starter. For the many reasons I have described in the various
> > postings I have made today.
> >
> > It is entirely impractical
David Miller wrote:
> From: Phil Sutter
> Date: Mon, 19 Feb 2018 18:14:11 +0100
>
> > OK, so reading between the lines you're saying that nftables project
> > has failed to provide an adequate successor to iptables?
>
> Whilst it is great that the atomic table update problem was solved, I
> thi
Hi David,
On Mon, Feb 19, 2018 at 01:41:29PM -0500, David Miller wrote:
> From: Phil Sutter
> Date: Mon, 19 Feb 2018 19:05:51 +0100
>
> > On Mon, Feb 19, 2018 at 12:22:26PM -0500, David Miller wrote:
> >> From: Phil Sutter
> >> Date: Mon, 19 Feb 2018 18:14:11 +0100
> >>
> >> > OK, so reading b
From: Harald Welte
Date: Mon, 19 Feb 2018 19:37:30 +0100
> I was speaking of actual *users* as in indiiduals running their own
> systems, companies running their own servers/datacenter. The fact that
> some ISP (or its supplier) decisdes that one of my IP packets is routed
> via a smartnic with
From: Arturo Borrero Gonzalez
Date: Mon, 19 Feb 2018 19:06:12 +0100
> Yes, probably major datacenters (google? facebook?, amazon?) they
> don't even care about what Debian is doing, since they are crafting
> their own distro anyway. But there are *a lot* of other people that
> do care about thes
From: Phil Sutter
Date: Mon, 19 Feb 2018 19:05:51 +0100
> Hi David,
>
> On Mon, Feb 19, 2018 at 12:22:26PM -0500, David Miller wrote:
>> From: Phil Sutter
>> Date: Mon, 19 Feb 2018 18:14:11 +0100
>>
>> > OK, so reading between the lines you're saying that nftables project
>> > has failed to pr
Hi David,
On Mon, Feb 19, 2018 at 12:29:08PM -0500, David Miller wrote:
> People with an Android phone in their pocket is using iptables, and
> the overhead and performance of those rules really does matter. It
> determines how long your battery life is, etc.
I am not the android expert. Howeve
On 19 February 2018 at 16:36, David Miller wrote:
>
> In my opinion, any resistence to integration with eBPF and XDP will
> lead to even less adoption of netfilter as a technology.
>
> Therefore my plan is to move everything to be integrated around these
> important core technologies. For the pur
Hi David,
On Mon, Feb 19, 2018 at 12:22:26PM -0500, David Miller wrote:
> From: Phil Sutter
> Date: Mon, 19 Feb 2018 18:14:11 +0100
>
> > OK, so reading between the lines you're saying that nftables project
> > has failed to provide an adequate successor to iptables?
>
> Whilst it is great that
On 19 February 2018 at 16:27, David Miller wrote:
> From: Florian Westphal
> Date: Mon, 19 Feb 2018 16:15:55 +0100
>
>> Would you be willing to merge nftables into kernel tools directory
>> then?
>
> Did you miss the part where I explained that people explicitly disable
> NFTABLES in their kernel
On 19 February 2018 at 16:36, David Miller wrote:
>
> I think netfilter is at a real crossroads right now.
>
I don't think so. The Netfilter Project and the Netfilter Community
already "agreed" on nftables and we are working on it.
But this isn't a secret, right? We have been open-discussing and
Hi David,
On Mon, Feb 19, 2018 at 10:31:39AM -0500, David Miller wrote:
> > Why is it practical to replace your kernel but not practical to replace
> > a small userspace tool running on top of it?
>
> The container is just userspace components. Those are really baked in
> and are never changing.
From: Harald Welte
Date: Mon, 19 Feb 2018 18:20:40 +0100
> It's like with any migration. People were using ipchains for a long
> time even after iptables existed. Many people simply don't care
> about packet filter performance. It's only a small fraction of their
> entire CPU workload, so prob
From: Phil Sutter
Date: Mon, 19 Feb 2018 18:14:11 +0100
> OK, so reading between the lines you're saying that nftables project
> has failed to provide an adequate successor to iptables?
Whilst it is great that the atomic table update problem was solved, I
think the emphasis on flexibility often
Hi David,
On Mon, Feb 19, 2018 at 10:36:51AM -0500, David Miller wrote:
> nftables has been proported as "better" for years, yet large
> institutions did not migrate to it. In fact, they explicitly
> disabled NFTABLES in their kernel config.
It's like with any migration. People were using ipch
From: Phil Sutter
Date: Mon, 19 Feb 2018 18:09:39 +0100
> What puzzles me about your argumentation is that you seem to propose for
> the kernel to cover up flaws in userspace. Spinning this concept further
> would mean that if there would be an old bug in iproute2 we should think
> of adding a wo
Hi David,
On Mon, Feb 19, 2018 at 10:44:59AM -0500, David Miller wrote:
> From: Harald Welte
> Date: Mon, 19 Feb 2018 16:38:08 +0100
>
> > On Mon, Feb 19, 2018 at 10:27:27AM -0500, David Miller wrote:
> >> > Would you be willing to merge nftables into kernel tools directory
> >> > then?
> >>
>
Hi David,
On Mon, Feb 19, 2018 at 10:31:39AM -0500, David Miller wrote:
> From: Harald Welte
> Date: Mon, 19 Feb 2018 16:27:46 +0100
>
> > On Mon, Feb 19, 2018 at 10:13:35AM -0500, David Miller wrote:
> >
> >> Florian, first of all, the whole "change the iptables binary" idea is
> >> a non-star
From: Harald Welte
Date: Mon, 19 Feb 2018 16:38:08 +0100
> On Mon, Feb 19, 2018 at 10:27:27AM -0500, David Miller wrote:
>> > Would you be willing to merge nftables into kernel tools directory
>> > then?
>>
>> Did you miss the part where I explained that people explicitly disable
>> NFTABLES in
From: Jan Engelhardt
Date: Mon, 19 Feb 2018 16:37:57 +0100 (CET)
> On Monday 2018-02-19 16:32, David Miller wrote:
>
>>From: Harald Welte
>>Date: Mon, 19 Feb 2018 16:23:21 +0100
>>
>>> Also, as long as legacy ip_tables/x_tables is still in the kernel, you
>>> can still run your old userspace ag
Dear David,
On Mon, Feb 19, 2018 at 10:27:27AM -0500, David Miller wrote:
> > Would you be willing to merge nftables into kernel tools directory
> > then?
>
> Did you miss the part where I explained that people explicitly disable
> NFTABLES in their kernel configs in most if not all large datacen
On Monday 2018-02-19 16:32, David Miller wrote:
>From: Harald Welte
>Date: Mon, 19 Feb 2018 16:23:21 +0100
>
>> Also, as long as legacy ip_tables/x_tables is still in the kernel, you
>> can still run your old userspace against that old implementation in the
>> kernel.
>
>But without offloading, a
From: Harald Welte
Date: Mon, 19 Feb 2018 16:23:21 +0100
>> Like it or not iptables ABI based filtering is going to be in the data
>> path for many years if not a decade or more to come.
>
> I beg to differ. For some people, yes. but then, as Florian points
> out, they can just as well use t
From: Harald Welte
Date: Mon, 19 Feb 2018 16:23:21 +0100
> Also, as long as legacy ip_tables/x_tables is still in the kernel, you
> can still run your old userspace against that old implementation in the
> kernel.
But without offloading, and the various other benefits which I have
tried to clear
From: Harald Welte
Date: Mon, 19 Feb 2018 16:27:46 +0100
> On Mon, Feb 19, 2018 at 10:13:35AM -0500, David Miller wrote:
>
>> Florian, first of all, the whole "change the iptables binary" idea is
>> a non-starter. For the many reasons I have described in the various
>> postings I have made toda
Hi David,
On Mon, Feb 19, 2018 at 10:13:35AM -0500, David Miller wrote:
> Florian, first of all, the whole "change the iptables binary" idea is
> a non-starter. For the many reasons I have described in the various
> postings I have made today.
>
> It is entirely impractical.
Why is it practica
Hi David,
On Mon, Feb 19, 2018 at 09:44:51AM -0500, David Miller wrote:
> I see talk about "just replacing the iptables binary".
>
> A long time ago in a galaxy far far away, that would be a reasonable
> scheme. But that kind of approach won't work in the realities of
> today.
>
> You aren't goi
From: Florian Westphal
Date: Mon, 19 Feb 2018 16:20:23 +0100
> See my other mail, where I explained, in great detail, the problems
> of the xtables UAPI.
As the person who wrote the bpfilter UAPI parser for this, you don't
need to explain this to me.
But it's not going anywhere, and is used by
From: Florian Westphal
Date: Mon, 19 Feb 2018 16:15:55 +0100
> Would you be willing to merge nftables into kernel tools directory
> then?
Did you miss the part where I explained that people explicitly disable
NFTABLES in their kernel configs in most if not all large datacenters?
David Miller wrote:
> From: Florian Westphal
> Date: Mon, 19 Feb 2018 15:53:14 +0100
>
> > Sure, but looking at all the things that were added to iptables
> > to alleviate some of the issues (ipset for instance) show that we need a
> > meaningful re-design of how things work conceptually.
>
> A
David Miller wrote:
> From: Florian Westphal
> Date: Mon, 19 Feb 2018 15:59:35 +0100
>
> > David Miller wrote:
> >> It also means that the scope of developers who can contribute and work
> >> on the translater is much larger.
> >
> > How so? Translator is in userspace in nftables case too?
>
From: Florian Westphal
Date: Mon, 19 Feb 2018 15:59:35 +0100
> David Miller wrote:
>> It also means that the scope of developers who can contribute and work
>> on the translater is much larger.
>
> How so? Translator is in userspace in nftables case too?
Florian, first of all, the whole "chan
From: Florian Westphal
Date: Mon, 19 Feb 2018 15:53:14 +0100
> Sure, but looking at all the things that were added to iptables
> to alleviate some of the issues (ipset for instance) show that we need a
> meaningful re-design of how things work conceptually.
As you said iptables is in maintainena
David Miller wrote:
> From: Daniel Borkmann
> Date: Mon, 19 Feb 2018 13:03:17 +0100
>
> > Thought was that it would be more suitable to push all the complexity of
> > such translation into user space which brings couple of additional
> > advantages
> > as well: the translation can become very c
From: Daniel Borkmann
Date: Mon, 19 Feb 2018 13:03:17 +0100
> Thought was that it would be more suitable to push all the complexity of
> such translation into user space which brings couple of additional advantages
> as well: the translation can become very complex and thus it would contain
> all
David Miller wrote:
> > How many of those wide-spread applications are you aware of? The two
> > projects you have pointed out (docker and kubernetes) don't. As the
> > assumption that many such tools would need to be supported drives a lot
> > of the design decisions, I would argue one needs a s
From: Harald Welte
Date: Mon, 19 Feb 2018 13:52:18 +0100
>> Right, having a custom iptables, libiptc or LD_PRELOAD approach would work
>> as well of course, but it still wouldn't address applications that have
>> their own custom libs programmed against iptables uapi directly or those
>> that reu
Hi Daniel,
On Mon, Feb 19, 2018 at 01:03:17PM +0100, Daniel Borkmann wrote:
> Hi Harald,
>
> On 02/17/2018 01:11 PM, Harald Welte wrote:
> [...]
> >> As rule translation can potentially become very complex, this is performed
> >> entirely in user space. In order to ease deployment, request_module
Hi Harald,
On 02/17/2018 01:11 PM, Harald Welte wrote:
[...]
>> As rule translation can potentially become very complex, this is performed
>> entirely in user space. In order to ease deployment, request_module() code
>> is extended to allow user mode helpers to be invoked. Idea is that user mode
>
Daniel Borkmann wrote:
> As rule translation can potentially become very complex, this is performed
> entirely in user space. In order to ease deployment, request_module() code
> is extended to allow user mode helpers to be invoked. Idea is that user mode
> helpers are built as part of the kernel
Harald Welte wrote:
> I believe _if_ one wants to use the approach of "hiding" eBPF behind
> iptables, then either
[..]
> b) you must introduce new 'tables', like an 'xdp' table which then has
>the notion of processing very early in processing, way before the
>normal filter table INPUT pro
Florian Westphal wrote:
> David Miller wrote:
> > From: Florian Westphal
> > Date: Fri, 16 Feb 2018 17:14:08 +0100
> >
> > > Any particular reason why translating iptables rather than nftables
> > > (it should be possible to monitor the nftables changes that are
> > > announced by kernel and a
David Miller wrote:
> From: Florian Westphal
> Date: Fri, 16 Feb 2018 17:14:08 +0100
>
> > Any particular reason why translating iptables rather than nftables
> > (it should be possible to monitor the nftables changes that are
> > announced by kernel and act on those)?
>
> As Daniel said, ipta
Daniel Borkmann wrote:
> Hi Florian,
>
> On 02/16/2018 05:14 PM, Florian Westphal wrote:
> > Florian Westphal wrote:
> >> Daniel Borkmann wrote:
> >> Several questions spinning at the moment, I will probably come up with
> >> more:
> >
> > ... and here there are some more ...
> >
> > One of t
Hi Daniel,
On Fri, Feb 16, 2018 at 02:40:19PM +0100, Daniel Borkmann wrote:
> This is a very rough and early proof of concept that implements bpfilter.
> The basic idea of bpfilter is that it can process iptables queries and
> translate them in user space into BPF programs which can then get attac
Hi Daniel,
On Fri, Feb 16, 2018 at 09:44:01PM +0100, Daniel Borkmann wrote:
> We started out with the
> iptables part in the demo as the majority of bigger infrastructure projects
> all still rely heavily on it (e.g. docker, k8s to just name two big ones).
docker is exec'ing the iptables command
Hi David,
On Fri, Feb 16, 2018 at 05:33:54PM -0500, David Miller wrote:
> From: Florian Westphal
>
> > Any particular reason why translating iptables rather than nftables
> > (it should be possible to monitor the nftables changes that are
> > announced by kernel and act on those)?
>
> As Danie
From: Florian Westphal
Date: Fri, 16 Feb 2018 17:14:08 +0100
> Any particular reason why translating iptables rather than nftables
> (it should be possible to monitor the nftables changes that are
> announced by kernel and act on those)?
As Daniel said, iptables is by far the most deployed of t
From: Florian Westphal
Date: Fri, 16 Feb 2018 15:57:27 +0100
> 4. Do you plan to reimplement connection tracking in userspace?
> If no, how will the bpf program interact with it?
The natural way to handle this, as with anything BPF related, is with
appropriate BPF helpers which would be added fo
Hi Florian,
On 02/16/2018 05:14 PM, Florian Westphal wrote:
> Florian Westphal wrote:
>> Daniel Borkmann wrote:
>> Several questions spinning at the moment, I will probably come up with
>> more:
>
> ... and here there are some more ...
>
> One of the many pain points of xtables design is the a
Hi Florian,
thanks for your feedback! More inline:
On 02/16/2018 03:57 PM, Florian Westphal wrote:
> Daniel Borkmann wrote:
>> This is a very rough and early proof of concept that implements bpfilter.
>
> [..]
>
>> Also, as a benefit from such design, we get BPF JIT compilation on x86_64,
>> a
Florian Westphal wrote:
> Daniel Borkmann wrote:
> Several questions spinning at the moment, I will probably come up with
> more:
... and here there are some more ...
One of the many pain points of xtables design is the assumption of 'used
only by sysadmin'.
This has not been true for a very l
Daniel Borkmann wrote:
> This is a very rough and early proof of concept that implements bpfilter.
[..]
> Also, as a benefit from such design, we get BPF JIT compilation on x86_64,
> arm64, ppc64, sparc64, mips64, s390x and arm32, but also rule offloading
> into HW for free for Netronome NFP Sma
This is a very rough and early proof of concept that implements bpfilter.
The basic idea of bpfilter is that it can process iptables queries and
translate them in user space into BPF programs which can then get attached
at various locations. For simplicity, in this RFC we demo attaching them
to XDP
68 matches
Mail list logo
