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]

Message-ID: <20150430004839.GG7025@acer.localdomain>
Date:	Thu, 30 Apr 2015 02:48:39 +0200
From:	Patrick McHardy <kaber@...sh.net>
To:	Daniel Borkmann <daniel@...earbox.net>
Cc:	Pablo Neira Ayuso <pablo@...filter.org>,
	netfilter-devel@...r.kernel.org, davem@...emloft.net,
	netdev@...r.kernel.org, jhs@...atatu.com
Subject: Re: [PATCH 6/6] net: move qdisc ingress filtering on top of
 netfilter ingress hooks

On 30.04, Daniel Borkmann wrote:
> On 04/30/2015 02:30 AM, Patrick McHardy wrote:
> >On 30.04, Daniel Borkmann wrote:
> >>>
> >>>I can also see there were also intentions to support userspace
> >>>queueing at some point since TC_ACT_QUEUED has been there since the
> >>>beginning.  That should be possible at some point using this
> >>>infrastructure (once there are no further concerns on the
> >>>netif_receive_core_finish() patch as soon as gcc 4.9 and follow up
> >>>versions keep inlining this new function).
> >>
> >>Wrt the other mail, just thinking out loud ... do you see a longer-term
> >>possibility of further generalizing the gen hooks infrastructure, so that
> >>actually classifier from tc could attach (disregarding the nf_* naming
> >>scheme for now) ...
> >>
> >>     `-> nf_hook_slow()
> >>      `-> [for each entry in hook list]   <-- here as an entry
> >>       `-> nf_iterate()
> >>        `-> (*elemp)->hook()
> >>
> >>... as well?
> >
> >Jumping in there since I'm probably the one thinking the TC ingress
> >abstraction is wrong the strongest - yes, it's an interesting idea.
> >Unlike egress qdiscs, ingress only has a single classifier chain
> >anyways, so there is no qdisc internal classification structure to
> 
> Yes, exactly.
> 
> >be observed. It should be possible to skip the ingress invocation
> >for classification purposes completely and only use it to expose
> >it to userspace for management purposes, while invoking the chain
> >directly.
> 
> That would also meet our goals to only have a single classifier
> chain, eventually. ;)

For TC, yes. What Pablo is trying to achieve (and I agree that it's
worthwhile) is multiple things:

* have people use TC ingress as before, obviously
* have people use netfilter, if they prefer
* have them combine both if for some unfortunate reason they require it

Netfilter is based on hook chains. The cost when only using a single hook
is minimal (as Pablo showed in his numbers), but even if only using
TC and a single netfilter classifier chain, there has to be some relative
ordering and the hooks provide this in a generic way.

So I'm all in favour of reduing costs for single or for multi-hook
cases, but it wouldn't be usable for us anymore when doing away with
multiple hooks completely.

One more point to consider is - this is generic infrastructure - the
next person requiring a hook will not have to touch the ingress path
at all. He can register with the hooks, having zero additional costs
for people not using it.
--
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