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: <55417545.30103@iogearbox.net>
Date:	Thu, 30 Apr 2015 02:20:21 +0200
From:	Daniel Borkmann <daniel@...earbox.net>
To:	Pablo Neira Ayuso <pablo@...filter.org>
CC:	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 01:32 AM, Pablo Neira Ayuso wrote:
...
>> Therefore, I think it would be better to not wrap that ingress qdisc
>> part of the patch set into even more layers. What do you think?
>
> I think the main front to improve performance in qdisc ingress is to
> remove the central spinlock that is harming scalability. There's also
> the built-in rule counters there that look problematic. So I would
> focus on improving performance from the qdisc ingress core
> infrastructure itself.
>
> On the bugfix front, the illegal mangling of shared skb from actions
> like stateless nat and bpf look also important to be addressed to me.
> David already suggested to propagate some state object that keeps a
> pointer to the skb that is passed to the action. Thus, the action can
> clone it and get the skb back to the ingress path. I started a
> patchset to do so here, it's a bit large since it requires quite a lot
> of function signature adjustment.
>
> 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?

Thanks,
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