netdev - Re: [PATCH RFC 0/4] net: add bpfilter

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 19 Feb 2018 18:14:11 +0100
From:   Phil Sutter <phil@....cc>
To:     David Miller <davem@...emloft.net>
Cc:     laforge@...monks.org, fw@...len.de, daniel@...earbox.net,
        netdev@...r.kernel.org, netfilter-devel@...r.kernel.org,
        alexei.starovoitov@...il.com
Subject: Re: [PATCH RFC 0/4] net: add bpfilter

Hi David,

On Mon, Feb 19, 2018 at 10:44:59AM -0500, David Miller wrote:
> From: Harald Welte <laforge@...monks.org>
> 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 their kernel configs in most if not all large datacenters?
> > 
> > If people to chose to disable a certain feature, then that is their own
> > decision to do so.  We should respect that decision.  Clearly they seem
> > to have no interest in a better or more featureful packet filter, then.
> > 
> > I mean, it's not like somebody proposes to implement NTFS inside the FAT
> > filesystem kernel module because distributors (or data centers) tend to
> > disable the NTFS module?!
> > 
> > How is kernel development these days constrained by what some users may
> > or may not put in their Kconfig?  If they want a given feature, they
> > must enable it.
> 
> This discussion was about why iptables UABI still matters.
> 
> And I'm trying to explain to you one of several reasons why it does.
> 
> Also, instead of saying "They decided to not use NFTABLES, oh well
> that is their problem" it might be more beneficial, especially in the
> long term for netfilter, to think about "why".

OK, so reading between the lines you're saying that nftables project has
failed to provide an adequate successor to iptables?

Cheers, Phil