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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 23 Nov 2019 15:23:05 +0100 From: Lukas Wunner <lukas@...ner.de> To: Daniel Borkmann <daniel@...earbox.net> Cc: Pablo Neira Ayuso <pablo@...filter.org>, Jozsef Kadlecsik <kadlec@...filter.org>, Florian Westphal <fw@...len.de>, netfilter-devel@...r.kernel.org, coreteam@...filter.org, netdev@...r.kernel.org, Martin Mares <mj@....cz> Subject: Re: [PATCH nf-next,RFC 5/5] netfilter: Introduce egress hook On Thu, Oct 31, 2019 at 11:39:58PM +0100, Daniel Borkmann wrote: > On 10/31/19 2:41 PM, Lukas Wunner wrote: > > Commit e687ad60af09 ("netfilter: add netfilter ingress hook after > > handle_ing() under unique static key") introduced the ability to > > classify packets on ingress. > > > > Allow the same on egress. > > > > The need for this arose because I had to filter egress packets which do > > not match a specific ethertype. The most common solution appears to be > > to enslave the interface to a bridge and use ebtables, but that's > > cumbersome to configure and comes with a (small) performance penalty. > > An alternative approach is tc, but that doesn't afford equivalent > > matching options as netfilter. > > Hmm, have you tried tc BPF on the egress hook (via sch_cls_act -> cls_bpf)? There's another reason I chose netfilter over tc: I need to activate the filter from a kernel module, hence need an in-kernel (rather than user space) API. netfilter provides that via nf_register_net_hook(), I couldn't find anything similar for tc. And an egress netfilter hook seemed like an obvious missing feature given the presence of an ingress hook. The module I need this for is out-of-tree: https://github.com/RevolutionPi/piControl/commit/da199ccd2099 In my experience the argument that a feature is needed for an out-of-tree module holds zero value upstream. If there's no in-tree user, the feature isn't merged, I've seen this more than enough. Which is why I didn't mention it in the first place. For our use case I wouldn't even need the nft user space support which I posted separately, I just implemented it for completeness and to increase acceptability of the present series. Thanks, Lukas
Powered by blists - more mailing lists