netdev - Re: [PATCH bpf-next v3 7/9] net/netfilter: Add unstable CT lookup helpers for XDP and TC-BPF

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] [day] [month] [year] [list]

Message-ID: <Ybp/J5KXn0hLT4DZ@salvia>
Date:   Thu, 16 Dec 2021 00:49:59 +0100
From:   Pablo Neira Ayuso <pablo@...filter.org>
To:     Toke Høiland-Jørgensen <toke@...hat.com>
Cc:     Kumar Kartikeya Dwivedi <memxor@...il.com>, bpf@...r.kernel.org,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andrii@...nel.org>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        John Fastabend <john.fastabend@...il.com>,
        Maxim Mikityanskiy <maximmi@...dia.com>,
        Florian Westphal <fw@...len.de>,
        Jesper Dangaard Brouer <brouer@...hat.com>,
        netdev@...r.kernel.org, netfilter-devel@...r.kernel.org
Subject: Re: [PATCH bpf-next v3 7/9] net/netfilter: Add unstable CT lookup
 helpers for XDP and TC-BPF

On Mon, Dec 13, 2021 at 10:25:37PM +0100, Toke Høiland-Jørgensen wrote:
> Pablo Neira Ayuso <pablo@...filter.org> writes:
> 
> > On Sat, Dec 11, 2021 at 07:35:58PM +0100, Toke Høiland-Jørgensen wrote:
> >> Pablo Neira Ayuso <pablo@...filter.org> writes:
> >> 
> >> > On Fri, Dec 10, 2021 at 09:01:29PM +0530, Kumar Kartikeya Dwivedi wrote:
> >> >> On Fri, Dec 10, 2021 at 08:39:14PM IST, Pablo Neira Ayuso wrote:
> >> >> > On Fri, Dec 10, 2021 at 06:32:28PM +0530, Kumar Kartikeya Dwivedi wrote:
> >> >> > [...]
> >> >> > >  net/netfilter/nf_conntrack_core.c | 252 ++++++++++++++++++++++++++++++
> >> >> > >  7 files changed, 497 insertions(+), 1 deletion(-)
> >> >> > >
> >> >> > [...]
> >> >> > > diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
> >> >> > > index 770a63103c7a..85042cb6f82e 100644
> >> >> > > --- a/net/netfilter/nf_conntrack_core.c
> >> >> > > +++ b/net/netfilter/nf_conntrack_core.c
> >> >> >
> >> >> > Please, keep this new code away from net/netfilter/nf_conntrack_core.c
> >> >> 
> >> >> Ok. Can it be a new file under net/netfilter, or should it live elsewhere?
> >> >
> >> > IPVS and OVS use conntrack for already quite a bit of time and they
> >> > keep their code in their respective folders.
> >> 
> >> Those are users, though.
> >
> > OK, I see this as a yet user of the conntrack infrastructure.
> 
> The users are the BPF programs; this series adds the exports. I.e., the
> code defines an API that BPF programs can hook into, and implements the
> validation and lifetime enforcement that is necessary for the particular
> data structures being exposed. This is very much something that the
> module doing the exports should be concerned with, so from that
> perspective it makes sense to keep it in the nf_conntrack kmod.

Thanks for explaining.

> >> This is adding a different set of exported functions, like a BPF
> >> version of EXPORT_SYMBOL(). We don't put those outside the module
> >> where the code lives either...
> >
> > OVS and IPVS uses Kconfig to enable the conntrack module as a
> > dependency. Then, add module that is loaded when conntrack is used.
> 
> BPF can't do that, though: all the core BPF code is always built into
> the kernel, so we can't have any dependencies on module code. Until now,
> this has meant that hooking into modules has been out of scope for BPF
> entirely. With kfuncs and the module BTF support this is now possible,
> but it's a bit "weird" (i.e., different) compared to what we're used to
> with kernel modules.

OK.

> This series represents the first instance of actually implementing BPF
> hooks into a module, BTW, so opinions on how to do it best are
> absolutely welcome. But I have a hard time seeing how this could be done
> without introducing *any* new code into the conntrack module...

OK, move on then and let's take the time to revisit.

Thanks.