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

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210930072835.791085f3@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Thu, 30 Sep 2021 07:28:35 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Pablo Neira Ayuso <pablo@...filter.org>
Cc:     Daniel Borkmann <daniel@...earbox.net>,
        netfilter-devel@...r.kernel.org, davem@...emloft.net,
        netdev@...r.kernel.org, lukas@...ner.de, kadlec@...filter.org,
        fw@...len.de, ast@...nel.org, edumazet@...gle.com, tgraf@...g.ch,
        nevola@...il.com, john.fastabend@...il.com, willemb@...gle.com
Subject: Re: [PATCH nf-next v5 0/6] Netfilter egress hook

On Thu, 30 Sep 2021 11:21:42 +0200 Pablo Neira Ayuso wrote:
> On Thu, Sep 30, 2021 at 09:33:23AM +0200, Daniel Borkmann wrote:
> > On 9/30/21 9:19 AM, Pablo Neira Ayuso wrote:  
> > > 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".  
> 
> I said distributors traditionally select the option that we signal to
> them, which is to enable this as module. We can document this in
> Kconfig. I think distributors should select whatever is better for
> their needs.
> 
> Anyway, I'll tell you why module blacklisting is bad: It is a hammer,
> it is a band aid to a problem. Blacklisting is just making things
> worst because it makes some people believe that something is
> unfixable. Yes, it took me a while to figure out.
> 
> We already entered the let's bloat the skbuff for many years already,
> this is stuffing one more bit into the skbuff just because maybe users
> might break an existing setup when they load new rules to the new
> netfilter egress hook.

The lifetime of this information is constrained, can't it be a percpu
flag, like xmit_more?

> Probably the sysctl for this new egress hook is the way to go as you
> suggest.

Knobs is making users pay, let's do our best to avoid that.