[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8773f286-74ba-4efb-4a94-0c1f91d959bd@naccy.de>
Date: Fri, 6 Jan 2023 15:43:39 +0100
From: Quentin Deslandes <qde@...cy.de>
To: Florian Westphal <fw@...len.de>
CC: Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Andrii Nakryiko <andrii@...nel.org>,
Martin KaFai Lau <martin.lau@...ux.dev>,
Song Liu <song@...nel.org>, Yonghong Song <yhs@...com>,
John Fastabend <john.fastabend@...il.com>,
KP Singh <kpsingh@...nel.org>,
Stanislav Fomichev <sdf@...gle.com>,
Hao Luo <haoluo@...gle.com>, Jiri Olsa <jolsa@...nel.org>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
Mykola Lysenko <mykolal@...com>, Shuah Khan <shuah@...nel.org>,
Dmitrii Banshchikov <me@...que.spb.ru>,
<linux-kernel@...r.kernel.org>, <bpf@...r.kernel.org>,
<linux-kselftest@...r.kernel.org>, <netdev@...r.kernel.org>,
Kernel Team <kernel-team@...a.com>
Subject: Re: [PATCH bpf-next v3 00/16] bpfilter
Le 03/01/2023 à 12:45, Florian Westphal a écrit :
> Quentin Deslandes <qde@...cy.de> 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.
Powered by blists - more mailing lists