netdev - Re: [PATCH 6/6] net: move qdisc ingress filtering on top of netfilter ingress hooks

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:	Thu, 30 Apr 2015 18:09:25 +0200
From:	Daniel Borkmann <daniel@...earbox.net>
To:	Pablo Neira Ayuso <pablo@...filter.org>,
	Jamal Hadi Salim <jhs@...atatu.com>
CC:	Patrick McHardy <kaber@...sh.net>,
	Alexei Starovoitov <alexei.starovoitov@...il.com>,
	netfilter-devel@...r.kernel.org, davem@...emloft.net,
	netdev@...r.kernel.org
Subject: Re: [PATCH 6/6] net: move qdisc ingress filtering on top of netfilter
 ingress hooks

On 04/30/2015 05:33 PM, Pablo Neira Ayuso wrote:
...
> On Thu, Apr 30, 2015 at 07:55:22AM -0400, Jamal Hadi Salim wrote:
> [...]
>> Start with a zero rules. Add them logarithmically (with and without
>> traffic running). i.e in order of {0, 1, 10, 100, 1000, ...}
>> With a single rule you dont notice much difference. Start adding rules
>> and it becomes very obvious.
>
> I think the days of linear ruleset performance competitions are over,

Totally agree with you. You want to have a single classification pass
that parses the packet once and comes to a verdict immediately.

> we have better data structures to allow users to arrange the ruleset
> through the multidimensional dictionaries and the arbitrary state
> flows that minimize the number of inspections, which is what it harms
> performance when it comes to packet classification.

I think both have different use cases, though, but on cls_bpf side you
have maps infrastructure that is evolving as well. Not really speaking
about the other remaining classifiers, however. I also don't want to go
any further into this vim vs emacs debate. ;) And, personally, I also
don't have any issue offering alternatives to users.

However, I still disagree with moving ingress behind this artificial
barrier if it's just not necessary. I believe, in your RFC v1 patch,
you had a second ingress hook as a static key for nft, I tend to like
that much better consensus-wise. Both subsystems should not put
unnecessary barriers into their way, really.

Best,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html