Re: [PATCH nf-next v5 0/6] Netfilter egress hook

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 9/30/21 9:19 AM, Pablo Neira Ayuso wrote:
On Thu, Sep 30, 2021 at 08:08:53AM +0200, Daniel Borkmann wrote:
On 9/28/21 11:55 AM, Pablo Neira Ayuso wrote:
Hi,

This patchset v5 that re-adds the Netfilter egress:

1) Rename linux/netfilter_ingress.h to linux/netfilter_netdev.h
     from Lukas Wunner.

2) Generalize ingress hook file to accomodate egress support,
     from Lukas Wunner.

3) Modularize Netfilter ingress hook into nf_tables_netdev: Daniel
     Borkmann is requesting for a mechanism to allow to blacklist
     Netfilter, this allows users to blacklist this new module that
     includes ingress chain and the new egress chain for the netdev
     family. There is no other in-tree user of the ingress and egress
     hooks than this which might interfer with his matter.

4) Place the egress hook again before the tc egress hook as requested
     by Daniel Borkmann. Patch to add egress hook from Lukas Wunner.
     The Netfilter egress hook remains behind the static key, if unused
     performance degradation is negligible.

5) Add netfilter egress handling to af_packet.

Arguably, distributors might decide to compile nf_tables_netdev
built-in. Traditionally, distributors have compiled their kernels using
the default configuration that Netfilter Kconfig provides (ie. use
modules whenever possible). In any case, I consider that distributor
policy is out of scope in this discussion, providing a mechanism to
allow Daniel to prevent Netfilter ingress and egress chains to be loaded
should be sufficient IMHO.

Hm, so in the case of SRv6 users were running into a similar issue and commit
7a3f5b0de364 ("netfilter: add netfilter hooks to SRv6 data plane") [0] added
a new hook along with a sysctl which defaults the new hook to off.

The rationale for it was given as "the hooks are enabled via nf_hooks_lwtunnel
sysctl to make sure existing netfilter rulesets do not break." [0,1]

If the suggestion to flag the skb [2] one way or another from the tc forwarding
path (e.g. skb bit or per-cpu marker) is not technically feasible, then why not
do a sysctl toggle like in the SRv6 case?

I am already providing a global toggle to disable netdev
ingress/egress hooks?

In the SRv6 case that is not possible.

Why do you need you need a sysctl knob when my proposal is already
addressing your needs?

Well, it's not addressing anything ... you even mention it yourself "arguably,
distributors might decide to compile nf_tables_netdev built-in".



[Index of Archives]     [Netfitler Users]     [Berkeley Packet Filter]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux