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.
