| Message ID | 20221224000402.476079-1-qde@naccy.de (mailing list archive) |
|---|---|
| Headers | show |
| Series | bpfilter | expand |
On Sat, Dec 24, 2022 at 01:03:46AM +0100, Quentin Deslandes wrote: > > Due to poor hardware availability on my side, I've not been able to > benchmark those changes. I plan to get some numbers for the next iteration. Yeah. Performance numbers would be my main question :) > FORWARD filter chain is now supported, however, it's attached to > TC INGRESS along with INPUT filter chain. This is due to XDP not supporting > multiple programs to be attached. I could generate a single program > out of both INPUT and FORWARD chains, but that would prevent another > BPF program to be attached to the interface anyway. If a solution > exists to attach both those programs to XDP while allowing for other > programs to be attached, it requires more investigation. In the meantime, > INPUT and FORWARD filtering is supported using TC. I think we can ignore XDP chaining for now assuming that Daniel's bpf_link-tc work will be applicable to XDP as well, so we'll have a simple chaining for XDP eventually. As far as attaching to TC... I think it would be great to combine bpfilter codegen and attach to Florian's bpf hooks exactly at netfilter. See https://git.breakpoint.cc/cgit/fw/nf-next.git/commit/?h=nf_hook_jit_bpf_29&id=0c1ec06503cb8a142d3ad9f760b72d94ea0091fa With nf_hook_ingress() calling either into classic iptable or into bpf_prog_run_nf which is either generated by Florian's optimizer of nf chains or into bpfilter generated code would be ideal.
Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote: > codegen and attach to Florian's bpf hooks exactly at netfilter. > See > https://git.breakpoint.cc/cgit/fw/nf-next.git/commit/?h=nf_hook_jit_bpf_29&id=0c1ec06503cb8a142d3ad9f760b72d94ea0091fa FWIW I plan to submit this patchset for 6.2.
Quentin Deslandes <qde@naccy.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. 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. I was planning to look into "attach bpf progs to raw netfilter hooks" in Q1 2023, once the initial nf-bpf-codegen is merged.
Le 27/12/2022 à 19:22, Alexei Starovoitov a écrit : > On Sat, Dec 24, 2022 at 01:03:46AM +0100, Quentin Deslandes wrote: >> >> Due to poor hardware availability on my side, I've not been able to >> benchmark those changes. I plan to get some numbers for the next iteration. > > Yeah. Performance numbers would be my main question :) Hardware is on the way! :) >> FORWARD filter chain is now supported, however, it's attached to >> TC INGRESS along with INPUT filter chain. This is due to XDP not supporting >> multiple programs to be attached. I could generate a single program >> out of both INPUT and FORWARD chains, but that would prevent another >> BPF program to be attached to the interface anyway. If a solution >> exists to attach both those programs to XDP while allowing for other >> programs to be attached, it requires more investigation. In the meantime, >> INPUT and FORWARD filtering is supported using TC. > > I think we can ignore XDP chaining for now assuming that Daniel's bpf_link-tc work > will be applicable to XDP as well, so we'll have a simple chaining > for XDP eventually. > > As far as attaching to TC... I think it would be great to combine bpfilter > codegen and attach to Florian's bpf hooks exactly at netfilter. > See > https://git.breakpoint.cc/cgit/fw/nf-next.git/commit/?h=nf_hook_jit_bpf_29&id=0c1ec06503cb8a142d3ad9f760b72d94ea0091fa > With nf_hook_ingress() calling either into classic iptable or into bpf_prog_run_nf > which is either generated by Florian's optimizer of nf chains or into > bpfilter generated code would be ideal. That sounds interesting. If my understanding is correct, Florian's work doesn't yet allow for userspace-generated programs to be attached, which will be required for bpfilter.
Le 03/01/2023 à 12:45, Florian Westphal a écrit : > Quentin Deslandes <qde@naccy.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.
Quentin Deslandes <qde@naccy.de> wrote: > That sounds interesting. If my understanding is correct, Florian's > work doesn't yet allow for userspace-generated programs to be attached, > which will be required for bpfilter. Yes, but I started working on the attachment side. It doesn't depend on the nf-bpf generator patch set. I think I can share PoC/RFC draft next week.
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 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?
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 > > 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
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. 2) No support of device ifindex - it's hardcoded 3) No helper subprog for counters update Another problem is using iptables' blobs for tests and filter table initialization. While it saves lines something more maintainable should be done here. The plan for the next iteration: 1) Add a helper program for counters update 2) Handle ifindex Patches 1/2 adds definitions of the used types. Patch 3 adds logging to bpfilter. Patch 4 adds an associative map. Patch 5 add runtime context structure. Patches 6/7 add code generation infrastructure and TC code generator. Patches 8/9/10/11/12 add code for matches, targets, rules and table. Patch 13 adds code generation for table. Patch 14 handles hooked setsockopt(2) calls. Patch 15 adds filter table Patch 16 uses prepared code in main(). Due to poor hardware availability on my side, I've not been able to benchmark those changes. I plan to get some numbers for the next iteration. FORWARD filter chain is now supported, however, it's attached to TC INGRESS along with INPUT filter chain. This is due to XDP not supporting multiple programs to be attached. I could generate a single program out of both INPUT and FORWARD chains, but that would prevent another BPF program to be attached to the interface anyway. If a solution exists to attach both those programs to XDP while allowing for other programs to be attached, it requires more investigation. In the meantime, INPUT and FORWARD filtering is supported using TC. Most of the code in this series was written by Dmitrii Banshchikov, my changes are limited to v3. I've tried to reflect this fact in the commits by adding 'Co-developed-by:' and 'Signed-off-by:' for Dmitrii, please tell me this was done the wrong way. v2 -> v3 Chains: * Add support for FORWARD filter chain. * Add generation of BPF bytecode to assess whether a packet should be forwarded or not, using bpf_fib_lookup(). * Allow for multiple programs to be attached to TC. * Allow for multiple TC hooks to be used. Code generation: * Remove duplicated BPF bytecode generation. * Fix a bug regarding jump offset during generation. * Remove support for XDP from the series, as it's not currently used. Table: * Add new filter_table_update_counters() virtual call. It updates the table's counter stored in the ipt_entry structure. This way, when iptables tries to fetch the values of the counters, bpfilter only has to copy the ipt_entry cached in the table structure. Logging: * Refactor logging primitives. Sockopts: * Add support for userspace counters querying. Rule: * Store the rule's index inside struct rule, to each counters' map usage. v1 -> v2 Maps: * Use map_upsert instead of separate map_insert and map_update Matches: * Add a new virtual call - gen_inline. The call is used for * inline generating of a rule's match. Targets: * Add a new virtual call - gen_inline. The call is used for inline generating of a rule's target. Rules: * Add code generation for rules Table: * Add struct table_ops * Add map for table_ops * Add filter table * Reorganize the way filter table is initialized Sockopts: * Install/uninstall BPF programs while handling IPT_SO_SET_REPLACE Code generation: * Add first version of the code generation Dependencies: * Add libbpf v0 -> v1 IO: * Use ssize_t in pvm_read, pvm_write for total_bytes * Move IO functions into sockopt.c and main.c Logging: * Use LOGLEVEL_EMERG, LOGLEVEL_NOTICE, LOGLEVE_DEBUG while logging to /dev/kmsg * Prepend log message with <n> where n is log level * Conditionally enable BFLOG_DEBUG messages * Merge bflog.{h,c} into context.h Matches: * Reorder fields in struct match_ops for tight packing * Get rid of struct match_ops_map * Rename udp_match_ops to xt_udp * Use XT_ALIGN macro * Store payload size in match size * Move udp match routines into a separate file Targets: * Reorder fields in struct target_ops for tight packing * Get rid of struct target_ops_map * Add comments for convert_verdict function Rules: * Add validation Tables: * Combine table_map and table_list into table_index * Add validation Sockopts: * Handle IPT_SO_GET_REVISION_TARGET 1. https://lore.kernel.org/patchwork/patch/902785/ 2. https://lore.kernel.org/patchwork/patch/902783/ 3. https://kernel.ubuntu.com/~cking/stress-ng/stress-ng.pdf Quentin Deslandes (16): bpfilter: add types for usermode helper tools: add bpfilter usermode helper header bpfilter: add logging facility bpfilter: add map container bpfilter: add runtime context bpfilter: add BPF bytecode generation infrastructure bpfilter: add support for TC bytecode generation bpfilter: add match structure bpfilter: add support for src/dst addr and ports bpfilter: add target structure bpfilter: add rule structure bpfilter: add table structure bpfilter: add table code generation bpfilter: add setsockopt() support bpfilter: add filter table bpfilter: handle setsockopt() calls include/uapi/linux/bpfilter.h | 154 +++ net/bpfilter/Makefile | 16 +- net/bpfilter/codegen.c | 1040 +++++++++++++++++ net/bpfilter/codegen.h | 183 +++ net/bpfilter/context.c | 168 +++ net/bpfilter/context.h | 24 + net/bpfilter/filter-table.c | 344 ++++++ net/bpfilter/filter-table.h | 18 + net/bpfilter/logger.c | 52 + net/bpfilter/logger.h | 80 ++ net/bpfilter/main.c | 132 ++- net/bpfilter/map-common.c | 51 + net/bpfilter/map-common.h | 19 + net/bpfilter/match.c | 55 + net/bpfilter/match.h | 37 + net/bpfilter/rule.c | 286 +++++ net/bpfilter/rule.h | 37 + net/bpfilter/sockopt.c | 533 +++++++++ net/bpfilter/sockopt.h | 15 + net/bpfilter/table.c | 391 +++++++ net/bpfilter/table.h | 59 + net/bpfilter/target.c | 203 ++++ net/bpfilter/target.h | 57 + net/bpfilter/xt_udp.c | 111 ++ tools/include/uapi/linux/bpfilter.h | 175 +++ .../testing/selftests/bpf/bpfilter/.gitignore | 8 + tools/testing/selftests/bpf/bpfilter/Makefile | 57 + .../selftests/bpf/bpfilter/bpfilter_util.h | 80 ++ .../selftests/bpf/bpfilter/test_codegen.c | 338 ++++++ .../testing/selftests/bpf/bpfilter/test_map.c | 63 + .../selftests/bpf/bpfilter/test_match.c | 69 ++ .../selftests/bpf/bpfilter/test_rule.c | 56 + .../selftests/bpf/bpfilter/test_target.c | 83 ++ .../selftests/bpf/bpfilter/test_xt_udp.c | 48 + 34 files changed, 4999 insertions(+), 43 deletions(-) create mode 100644 net/bpfilter/codegen.c create mode 100644 net/bpfilter/codegen.h create mode 100644 net/bpfilter/context.c create mode 100644 net/bpfilter/context.h create mode 100644 net/bpfilter/filter-table.c create mode 100644 net/bpfilter/filter-table.h create mode 100644 net/bpfilter/logger.c create mode 100644 net/bpfilter/logger.h create mode 100644 net/bpfilter/map-common.c create mode 100644 net/bpfilter/map-common.h create mode 100644 net/bpfilter/match.c create mode 100644 net/bpfilter/match.h create mode 100644 net/bpfilter/rule.c create mode 100644 net/bpfilter/rule.h create mode 100644 net/bpfilter/sockopt.c create mode 100644 net/bpfilter/sockopt.h create mode 100644 net/bpfilter/table.c create mode 100644 net/bpfilter/table.h create mode 100644 net/bpfilter/target.c create mode 100644 net/bpfilter/target.h create mode 100644 net/bpfilter/xt_udp.c create mode 100644 tools/include/uapi/linux/bpfilter.h create mode 100644 tools/testing/selftests/bpf/bpfilter/.gitignore create mode 100644 tools/testing/selftests/bpf/bpfilter/Makefile create mode 100644 tools/testing/selftests/bpf/bpfilter/bpfilter_util.h create mode 100644 tools/testing/selftests/bpf/bpfilter/test_codegen.c create mode 100644 tools/testing/selftests/bpf/bpfilter/test_map.c create mode 100644 tools/testing/selftests/bpf/bpfilter/test_match.c create mode 100644 tools/testing/selftests/bpf/bpfilter/test_rule.c create mode 100644 tools/testing/selftests/bpf/bpfilter/test_target.c create mode 100644 tools/testing/selftests/bpf/bpfilter/test_xt_udp.c -- 2.38.1