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:
> > 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?
