On Thu, Sep 30, 2021 at 08:52:38AM +0200, Lukas Wunner wrote:

On Thu, Sep 30, 2021 at 08:08:53AM +0200, Daniel Borkmann wrote:

quoted

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?

The skb flag *is* technically feasible.  I amended the patches with
the flag and was going to post them this week, but Pablo beat me to
the punch and posted his alternative version, which lacks the flag
but modularizes netfilter ingress/egress processing instead.

Honestly I think a hodge-podge of config options and sysctl toggles
is awful and I would prefer the skb flag you suggested.  I kind of
like your idea of considering tc and netfilter as layers.

FWIW the finished patches *with* the flag are on this branch:
https://github.com/l1k/linux/commits/nft_egress_v5

Below is the "git range-diff" between Pablo's patches and mine
(just the hunks which pertain to the skb flag, plus excerpts
from the commit message).

Would you find the patch set acceptable with this skb flag?

Why do you need a programmatic skb flag?

Are you planning to do:

        skb->skip_nf_egress = random();

from the packet path?

Seriously, Daniel is asking for a global toggle to disable Netfilter.

What is wrong with the Netfilter blacklisting approach?