All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: Quentin Deslandes <qde@naccy.de>
Cc: Florian Westphal <fw@strlen.de>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Martin KaFai Lau <martin.lau@linux.dev>,
	Song Liu <song@kernel.org>, Yonghong Song <yhs@fb.com>,
	John Fastabend <john.fastabend@gmail.com>,
	KP Singh <kpsingh@kernel.org>,
	Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>,
	Jiri Olsa <jolsa@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Mykola Lysenko <mykolal@fb.com>, Shuah Khan <shuah@kernel.org>,
	Dmitrii Banshchikov <me@ubique.spb.ru>,
	linux-kernel@vger.kernel.org, bpf@vger.kernel.org,
	linux-kselftest@vger.kernel.org, netdev@vger.kernel.org,
	Kernel Team <kernel-team@meta.com>
Subject: Re: [PATCH bpf-next v3 00/16] bpfilter
Date: Thu, 12 Jan 2023 04:17:28 +0100	[thread overview]
Message-ID: <20230112031728.GL27644@breakpoint.cc> (raw)
In-Reply-To: <8773f286-74ba-4efb-4a94-0c1f91d959bd@naccy.de>

Quentin Deslandes <qde@naccy.de> wrote:
> Le 03/01/2023 à 12:45, Florian Westphal a écrit :
> > You can't make this atomic from userspace perspective, the
> > get/setsockopt API of iptables uses a read-modify-write model.
> 
> This refers to updating the programs from bpfilter's side. It won't
> be atomic from iptables point of view, but currently bpfilter will
> remove the program associated to a table, before installing the new
> one. This means packets received in between those operations are
> not filtered. I assume a better solution is possible.

Ah, I see, thanks.

> > Tentatively I'd try to extend libnftnl and generate bpf code there,
> > since its used by both iptables(-nft) and nftables we'd automatically
> > get support for both.
> 
> That's one of the option, this could also remain in the kernel
> tree or in a dedicated git repository. I don't know which one would
> be the best, I'm open to suggestions.

I can imagine that this will see a flurry of activity in the early
phase so I think a 'semi test repo' makes sense.

Provideded license allows this, useable bits and pieces can then
be grafted on to libnftnl (or iptables or whatever).

> > I was planning to look into "attach bpf progs to raw netfilter hooks"
> > in Q1 2023, once the initial nf-bpf-codegen is merged.
> 
> Is there any plan to support non raw hooks? That's mainly out
> of curiosity, I don't even know whether that would be a good thing
> or not.

Not sure what 'non raw hook' is.  Idea was to expose

1. protcocol family
2. hook number (prerouting, input etc)
3. priority

to userspace via bpf syscall/bpf link.

userspace would then provide the above info to kernel via
bpf(... BPF_LINK_CREATE )

which would then end up doing:
--------------
h.hook = nf_hook_run_bpf; // wrapper to call BPF_PROG_RUN
h.priv = prog; // the bpf program to run
h.pf = attr->netfilter.pf;
h.priority = attr->netfilter.priority;
h.hooknum = attr->netfilter.hooknum;

nf_register_net_hook(net, &h);
--------------

After that nf_hook_slow() calls the bpf program just like any
other of the netfilter hooks.

Does that make sense or did you have something else in mind?

  reply	other threads:[~2023-01-12  3:17 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-24  0:03 [PATCH bpf-next v3 00/16] bpfilter Quentin Deslandes
2022-12-24  0:03 ` [PATCH bpf-next v3 01/16] bpfilter: add types for usermode helper Quentin Deslandes
2022-12-24  0:03 ` [PATCH bpf-next v3 02/16] tools: add bpfilter usermode helper header Quentin Deslandes
2022-12-24  0:03 ` [PATCH bpf-next v3 03/16] bpfilter: add logging facility Quentin Deslandes
2022-12-24  0:03 ` [PATCH bpf-next v3 04/16] bpfilter: add map container Quentin Deslandes
2022-12-24  0:03 ` [PATCH bpf-next v3 05/16] bpfilter: add runtime context Quentin Deslandes
2022-12-24  0:03 ` [PATCH bpf-next v3 06/16] bpfilter: add BPF bytecode generation infrastructure Quentin Deslandes
2022-12-24  0:03 ` [PATCH bpf-next v3 07/16] bpfilter: add support for TC bytecode generation Quentin Deslandes
2022-12-24  0:03 ` [PATCH bpf-next v3 08/16] bpfilter: add match structure Quentin Deslandes
2022-12-24  0:03 ` [PATCH bpf-next v3 09/16] bpfilter: add support for src/dst addr and ports Quentin Deslandes
2022-12-24  0:03 ` [PATCH bpf-next v3 10/16] bpfilter: add target structure Quentin Deslandes
2022-12-24  0:03 ` [PATCH bpf-next v3 11/16] bpfilter: add rule structure Quentin Deslandes
2022-12-24  0:03 ` [PATCH bpf-next v3 12/16] bpfilter: add table structure Quentin Deslandes
2022-12-24  0:03 ` [PATCH bpf-next v3 13/16] bpfilter: add table code generation Quentin Deslandes
2022-12-24  0:04 ` [PATCH bpf-next v3 14/16] bpfilter: add setsockopt() support Quentin Deslandes
2022-12-24  0:04 ` [PATCH bpf-next v3 15/16] bpfilter: add filter table Quentin Deslandes
2022-12-24  0:04 ` [PATCH bpf-next v3 16/16] bpfilter: handle setsockopt() calls Quentin Deslandes
2022-12-27 18:22 ` [PATCH bpf-next v3 00/16] bpfilter Alexei Starovoitov
2023-01-03 11:38   ` Florian Westphal
2023-01-06 14:15   ` Quentin Deslandes
2023-01-12  3:03     ` Florian Westphal
2023-01-03 11:45 ` Florian Westphal
2023-01-06 14:43   ` Quentin Deslandes
2023-01-12  3:17     ` Florian Westphal [this message]
2023-01-25 10:25       ` Quentin Deslandes
  -- strict thread matches above, loose matches on Subject: below --
2022-12-23 23:40 Quentin Deslandes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230112031728.GL27644@breakpoint.cc \
    --to=fw@strlen.de \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=haoluo@google.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kernel-team@meta.com \
    --cc=kpsingh@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=me@ubique.spb.ru \
    --cc=mykolal@fb.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=qde@naccy.de \
    --cc=sdf@google.com \
    --cc=shuah@kernel.org \
    --cc=song@kernel.org \
    --cc=yhs@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.