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
| ||
|
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
Powered by blists - more mailing lists