On Thu, Jan 12, 2023 at 04:17:28AM +0100, Florian Westphal wrote:
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
- protcocol family
- hook number (prerouting, input etc)
- 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