On Thu, Jan 12, 2023 at 04:17:28AM +0100, Florian Westphal wrote: > Quentin Deslandes <qde@xxxxxxxx> 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? Sounds good to me. I thought you were referring to hooks available for the RAW table (as in `iptables --table raw...`). Thanks, Quentin
