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?
[0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7a3f5b0de3647c854e34269c3332d7a1e902901a
[1] https://lore.kernel.org/netdev/20210830093852.21654-1-pablo@xxxxxxxxxxxxx/
[2] https://lore.kernel.org/netdev/11584665-e3b5-3afe-d72c-ef92ad0b9313@xxxxxxxxxxxxx/
