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]

Date:   Thu, 30 Sep 2021 20:00:56 +0200
From:   Pablo Neira Ayuso <pablo@...filter.org>
To:     Jakub Kicinski <kuba@...nel.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, Sep 30, 2021 at 09:06:52AM -0700, Jakub Kicinski wrote:
> On Thu, 30 Sep 2021 17:13:37 +0200 Pablo Neira Ayuso wrote:
> > On Thu, Sep 30, 2021 at 07:28:35AM -0700, Jakub Kicinski wrote:
> > > The lifetime of this information is constrained, can't it be a percpu
> > > flag, like xmit_more?  
> > 
> > It's just one single bit in this case after all.
> 
> ??

There are "escape" points such ifb from ingress, where the packets gets
enqueued and then percpu might not help, it might be fragile to use
percpu in this case.

> > > > 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.  
> > 
> > Could you elaborate?
> 
> My reading of Daniel's objections was that the layering is incorrect
> because tc is not exclusively "under" nf. That problem is not solved 
> by adding a knob. The only thing the knob achieves is let someone
> deploying tc/bpf based solution protect themselves from accidental
> nf deployment.
> 
> That's just background / level set. IDK what requires explanation 
> in my statement itself. I thought "admin knobs are bad" is as
> universally agreed on as, say, "testing is good".

Yes, knobs are not ideal but Daniel mentioned it as a posibility, the
skbuff bit might not ideal either because it might be not easy to
debug the behaviour that it turns on to the user, but it could only be
set on from act_mirred, Daniel mentioned to cover only the
skb->redirect case.

Thanks