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 02:41:30 +0200
From:	Daniel Borkmann <daniel@...earbox.net>
To:	Patrick McHardy <kaber@...sh.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 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. ;)
--
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