Re: [PATCH bpf-next v3 00/16] bpfilter

[Quentin Deslandes]

Le 03/01/2023 à 12:45, Florian Westphal a écrit :
> Quentin Deslandes <qde@xxxxxxxx> wrote:
> > The patchset is based on the patches from David S. Miller [1],
> > Daniel Borkmann [2], and Dmitrii Banshchikov [3].
> >
> > Note: I've partially sent this patchset earlier due to a
> > mistake on my side, sorry for then noise.
> >
> > The main goal of the patchset is to prepare bpfilter for
> > iptables' configuration blob parsing and code generation.
> >
> > The patchset introduces data structures and code for matches,
> > targets, rules and tables. Beside that the code generation
> > is introduced.
> >
> > The first version of the code generation supports only "inline"
> > mode - all chains and their rules emit instructions in linear
> > approach.
> >
> > Things that are not implemented yet:
> >    1) The process of switching from the previous BPF programs to the
> >       new set isn't atomic.
>
> 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.

> 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 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.