| Message ID | cover.1687819413.git.dxu@dxuuu.xyz (mailing list archive) |
|---|---|
| Headers | show |
| Series | Support defragmenting IPv(4|6) packets in BPF | expand |
Daniel Xu <dxu@dxuuu.xyz> wrote: > Patches 1 & 2 are stolenfrom Florian. Hopefully he doesn't mind. There > were some outstanding comments on the v2 [2] but it doesn't look like a > v3 was ever submitted. I've addressed the comments and put them in this > patchset cuz I needed them. I did not submit a v3 because i had to wait for the bpf -> bpf-next merge to get "bpf: netfilter: Add BPF_NETFILTER bpf_attach_type". Now that has been done so I will do v3 shortly.
Hi Florian, On Tue, Jun 27, 2023 at 12:48:20PM +0200, Florian Westphal wrote: > Daniel Xu <dxu@dxuuu.xyz> wrote: > > Patches 1 & 2 are stolenfrom Florian. Hopefully he doesn't mind. There > > were some outstanding comments on the v2 [2] but it doesn't look like a > > v3 was ever submitted. I've addressed the comments and put them in this > > patchset cuz I needed them. > > I did not submit a v3 because i had to wait for the bpf -> bpf-next > merge to get "bpf: netfilter: Add BPF_NETFILTER bpf_attach_type". > > Now that has been done so I will do v3 shortly. Ack. Will wait for your patches to go in before sending my v2. Thanks, Daniel
> The basic idea is we bump a refcnt on the netfilter defrag module and > then run the bpf prog after the defrag module runs. This allows bpf > progs to transparently see full, reassembled packets. The nice thing > about this is that progs don't have to carry around logic to detect > fragments. One high-level comment after glancing through the series: Instead of allocating a flag specifically for the defrag module, why not support loading (and holding) arbitrary netfilter modules in the UAPI? If we need to allocate a new flag every time someone wants to use a netfilter module along with BPF we'll run out of flags pretty quickly :) -Toke
Hi Toke, Thanks for taking a look at the patchset. On Tue, Jun 27, 2023 at 04:25:13PM +0200, Toke Høiland-Jørgensen wrote: > > The basic idea is we bump a refcnt on the netfilter defrag module and > > then run the bpf prog after the defrag module runs. This allows bpf > > progs to transparently see full, reassembled packets. The nice thing > > about this is that progs don't have to carry around logic to detect > > fragments. > > One high-level comment after glancing through the series: Instead of > allocating a flag specifically for the defrag module, why not support > loading (and holding) arbitrary netfilter modules in the UAPI? If we > need to allocate a new flag every time someone wants to use a netfilter > module along with BPF we'll run out of flags pretty quickly :) I don't have enough context on netfilter in general to say if it'd be generically useful -- perhaps Florian can comment on that. However, I'm not sure such a mechanism removes the need for a flag. The netfilter defrag modules still need to be called into to bump the refcnt. The module could export some kfuncs to inc/dec the refcnt, but it'd be rather odd for prog code to think about the lifetime of the attachment (as inc/dec for _each_ prog execution seems wasteful and slow). AFAIK all the other resource acquire/release APIs are for a single prog execution. So a flag for link attach feels the most natural to me. We could always add a flag2 field or something right? [...] Thanks, Daniel
Toke Høiland-Jørgensen <toke@redhat.com> wrote: > > The basic idea is we bump a refcnt on the netfilter defrag module and > > then run the bpf prog after the defrag module runs. This allows bpf > > progs to transparently see full, reassembled packets. The nice thing > > about this is that progs don't have to carry around logic to detect > > fragments. > > One high-level comment after glancing through the series: Instead of > allocating a flag specifically for the defrag module, why not support > loading (and holding) arbitrary netfilter modules in the UAPI? How would that work/look like? defrag (and conntrack) need special handling because loading these modules has no effect on the datapath. Traditionally, yes, loading was enough, but now with netns being ubiquitous we don't want these to get enabled unless needed. Ignoring bpf, this happens when user adds nftables/iptables rules that check for conntrack state, use some form of NAT or use e.g. tproxy. For bpf a flag during link attachment seemed like the best way to go. At the moment I only see two flags for this, namely "need defrag" and "need conntrack". For conntrack, we MIGHT be able to not need a flag but maybe verifier could "guess" based on kfuncs used. But for defrag, I don't think its good to add a dummy do-nothing kfunc just for expressing the dependency on bpf prog side.
Florian Westphal <fw@strlen.de> writes: > Toke Høiland-Jørgensen <toke@redhat.com> wrote: >> > The basic idea is we bump a refcnt on the netfilter defrag module and >> > then run the bpf prog after the defrag module runs. This allows bpf >> > progs to transparently see full, reassembled packets. The nice thing >> > about this is that progs don't have to carry around logic to detect >> > fragments. >> >> One high-level comment after glancing through the series: Instead of >> allocating a flag specifically for the defrag module, why not support >> loading (and holding) arbitrary netfilter modules in the UAPI? > > How would that work/look like? > > defrag (and conntrack) need special handling because loading these > modules has no effect on the datapath. > > Traditionally, yes, loading was enough, but now with netns being > ubiquitous we don't want these to get enabled unless needed. > > Ignoring bpf, this happens when user adds nftables/iptables rules > that check for conntrack state, use some form of NAT or use e.g. tproxy. > > For bpf a flag during link attachment seemed like the best way > to go. Right, I wasn't disputing that having a flag to load a module was a good idea. On the contrary, I was thinking we'd need many more of these if/when BPF wants to take advantage of more netfilter code. Say, if a BPF module wants to call into TPROXY, that module would also need go be loaded and kept around, no? I was thinking something along the lines of just having a field 'netfilter_modules[]' where userspace could put an arbitrary number of module names into, and we'd load all of them and put a ref into the bpf_link. In principle, we could just have that be a string array of module names, but that's probably a bit cumbersome (and, well, building a generic module loader interface into the bpf_like API is not desirable either). But maybe with an explicit ENUM? > At the moment I only see two flags for this, namely > "need defrag" and "need conntrack". > > For conntrack, we MIGHT be able to not need a flag but > maybe verifier could "guess" based on kfuncs used. If the verifier can just identify the modules from the kfuncs and do the whole thing automatically, that would of course be even better from an ease-of-use PoV. Not sure what that would take, though? I seem to recall having discussions around these lines before that fell down on various points. > But for defrag, I don't think its good to add a dummy do-nothing > kfunc just for expressing the dependency on bpf prog side. Agreed. -Toke
Toke Høiland-Jørgensen <toke@redhat.com> wrote: > Florian Westphal <fw@strlen.de> writes: > > For bpf a flag during link attachment seemed like the best way > > to go. > > Right, I wasn't disputing that having a flag to load a module was a good > idea. On the contrary, I was thinking we'd need many more of these > if/when BPF wants to take advantage of more netfilter code. Say, if a > BPF module wants to call into TPROXY, that module would also need go be > loaded and kept around, no? That seems to be a different topic that has nothing to do with either bpf_link or netfilter? If the program calls into say, TPROXY, then I'd expect that this needs to be handled via kfuncs, no? Or if I misunderstand, what do you mean by "call into TPROXY"? And if so, thats already handled at bpf_prog load time, not at link creation time, or do I miss something here? AFAIU, if prog uses such kfuncs, verifier will grab needed module ref and if module isn't loaded the kfuncs won't be found and program load fails. > I was thinking something along the lines of just having a field > 'netfilter_modules[]' where userspace could put an arbitrary number of > module names into, and we'd load all of them and put a ref into the > bpf_link. Why? I fail to understand the connection between bpf_link, netfilter and modules. What makes netfilter so special that we need such a module array, and what does that have to do with bpf_link interface? > In principle, we could just have that be a string array f > module names, but that's probably a bit cumbersome (and, well, building > a generic module loader interface into the bpf_like API is not > desirable either). But maybe with an explicit ENUM? What functionality does that provide? I can't think of a single module where this functionality is needed. Either we're talking about future kfuncs, then, as far as i understand how kfuncs work, this is handled at bpf_prog load time, not when the bpf_link is created. Or we are talking about implicit dependencies, where program doesn't call function X but needs functionality handled earlier in the pipeline? The only two instances I know where this is the case for netfilter is defrag + conntrack. > > For conntrack, we MIGHT be able to not need a flag but > > maybe verifier could "guess" based on kfuncs used. > > If the verifier can just identify the modules from the kfuncs and do the > whole thing automatically, that would of course be even better from an > ease-of-use PoV. Not sure what that would take, though? I seem to recall > having discussions around these lines before that fell down on various > points. AFAICS the conntrack kfuncs are wired to nf_conntrack already, so I would expect that the module has to be loaded already for the verifier to accept the program. Those kfuncs are not yet exposed to NETFILTER program types. Once they are, all that would be needed is for the netfilter bpf_link to be able tp detect that the prog is calling into those kfuncs, and then make the needed register/unregister calls to enable the conntrack hooks. Wheter thats better than using an explicit "please turn on conntrack for me", I don't know. Perhaps future bpf programs could access skb->_nfct directly without kfuncs so I'd say the flag is a better approach from an uapi point of view.
Florian Westphal <fw@strlen.de> writes: > Toke Høiland-Jørgensen <toke@redhat.com> wrote: >> Florian Westphal <fw@strlen.de> writes: >> > For bpf a flag during link attachment seemed like the best way >> > to go. >> >> Right, I wasn't disputing that having a flag to load a module was a good >> idea. On the contrary, I was thinking we'd need many more of these >> if/when BPF wants to take advantage of more netfilter code. Say, if a >> BPF module wants to call into TPROXY, that module would also need go be >> loaded and kept around, no? > > That seems to be a different topic that has nothing to do with > either bpf_link or netfilter? > > If the program calls into say, TPROXY, then I'd expect that this needs > to be handled via kfuncs, no? Or if I misunderstand, what do you mean > by "call into TPROXY"? > > And if so, thats already handled at bpf_prog load time, not > at link creation time, or do I miss something here? > > AFAIU, if prog uses such kfuncs, verifier will grab needed module ref > and if module isn't loaded the kfuncs won't be found and program load > fails. ... > Or we are talking about implicit dependencies, where program doesn't > call function X but needs functionality handled earlier in the pipeline? > > The only two instances I know where this is the case for netfilter > is defrag + conntrack. Well, I was kinda mixing the two cases above, sorry about that. The "kfuncs locking the module" was not present in my mind when starting to talk about that bit... As for the original question, that's answered by your point above: If those two modules are the only ones that are likely to need this, then a flag for each is fine by me - that was the key piece I was missing (I'm not a netfilter expert, as you well know). Thanks for clarifying, and apologies for the muddled thinking! :) -Toke
Toke Høiland-Jørgensen <toke@redhat.com> wrote: > Florian Westphal <fw@strlen.de> writes: > As for the original question, that's answered by your point above: If > those two modules are the only ones that are likely to need this, then a > flag for each is fine by me - that was the key piece I was missing (I'm > not a netfilter expert, as you well know). No problem, I was worried I was missing an important piece of kfunc plumbing :-) You do raise a good point though. With kfuncs, module is pinned. So, should a "please turn on defrag for this bpf_link" pin the defrag modules too? For plain netfilter we don't do that, i.e. you can just do "rmmod nf_defrag_ipv4". But I suspect that for the new bpf-link defrag we probably should grab a reference to prevent unwanted functionality breakage of the bpf prog.
On Thu, Jun 29, 2023 at 04:53:15PM +0200, Florian Westphal wrote: > Toke Høiland-Jørgensen <toke@redhat.com> wrote: > > Florian Westphal <fw@strlen.de> writes: > > As for the original question, that's answered by your point above: If > > those two modules are the only ones that are likely to need this, then a > > flag for each is fine by me - that was the key piece I was missing (I'm > > not a netfilter expert, as you well know). > > No problem, I was worried I was missing an important piece of kfunc > plumbing :-) > > You do raise a good point though. With kfuncs, module is pinned. > So, should a "please turn on defrag for this bpf_link" pin > the defrag modules too? > > For plain netfilter we don't do that, i.e. you can just do > "rmmod nf_defrag_ipv4". But I suspect that for the new bpf-link > defrag we probably should grab a reference to prevent unwanted > functionality breakage of the bpf prog. Ack. Will add to v3. Thanks, Daniel
=== Context === In the context of a middlebox, fragmented packets are tricky to handle. The full 5-tuple of a packet is often only available in the first fragment which makes enforcing consistent policy difficult. There are really only two stateless options, neither of which are very nice: 1. Enforce policy on first fragment and accept all subsequent fragments. This works but may let in certain attacks or allow data exfiltration. 2. Enforce policy on first fragment and drop all subsequent fragments. This does not really work b/c some protocols may rely on fragmentation. For example, DNS may rely on oversized UDP packets for large responses. So stateful tracking is the only sane option. RFC 8900 [0] calls this out as well in section 6.3: Middleboxes [...] should process IP fragments in a manner that is consistent with [RFC0791] and [RFC8200]. In many cases, middleboxes must maintain state in order to achieve this goal. === BPF related bits === Policy has traditionally been enforced from XDP/TC hooks. Both hooks run before kernel reassembly facilities. However, with the new BPF_PROG_TYPE_NETFILTER, we can rather easily hook into existing netfilter reassembly infra. The basic idea is we bump a refcnt on the netfilter defrag module and then run the bpf prog after the defrag module runs. This allows bpf progs to transparently see full, reassembled packets. The nice thing about this is that progs don't have to carry around logic to detect fragments. === Patchset details === There was an earlier attempt at providing defrag via kfuncs [1]. The feedback was that we could end up doing too much stuff in prog execution context (like sending ICMP error replies). However, I think there are still some outstanding discussion w.r.t. performance when it comes to netfilter vs the previous approach. I'll schedule some time during office hours for this. Patches 1 & 2 are stolenfrom Florian. Hopefully he doesn't mind. There were some outstanding comments on the v2 [2] but it doesn't look like a v3 was ever submitted. I've addressed the comments and put them in this patchset cuz I needed them. Finally, the new selftest seems to be a little flaky. I'm not quite sure why the server will fail to `recvfrom()` occassionaly. I'm fairly sure it's a timing related issue with creating veths. I'll keep debugging but I didn't want that to hold up discussion on this patchset. [0]: https://datatracker.ietf.org/doc/html/rfc8900 [1]: https://lore.kernel.org/bpf/cover.1677526810.git.dxu@dxuuu.xyz/ [2]: https://lore.kernel.org/bpf/20230525110100.8212-1-fw@strlen.de/ Daniel Xu (7): tools: libbpf: add netfilter link attach helper selftests/bpf: Add bpf_program__attach_netfilter helper test netfilter: defrag: Add glue hooks for enabling/disabling defrag netfilter: bpf: Support BPF_F_NETFILTER_IP_DEFRAG in netfilter link bpf: selftests: Support not connecting client socket bpf: selftests: Support custom type and proto for client sockets bpf: selftests: Add defrag selftests include/linux/netfilter.h | 12 + include/uapi/linux/bpf.h | 5 + net/ipv4/netfilter/nf_defrag_ipv4.c | 8 + net/ipv6/netfilter/nf_defrag_ipv6_hooks.c | 10 + net/netfilter/core.c | 6 + net/netfilter/nf_bpf_link.c | 108 ++++++- tools/include/uapi/linux/bpf.h | 5 + tools/lib/bpf/bpf.c | 8 + tools/lib/bpf/bpf.h | 6 + tools/lib/bpf/libbpf.c | 47 +++ tools/lib/bpf/libbpf.h | 15 + tools/lib/bpf/libbpf.map | 1 + tools/testing/selftests/bpf/Makefile | 4 +- .../selftests/bpf/generate_udp_fragments.py | 90 ++++++ .../selftests/bpf/ip_check_defrag_frags.h | 57 ++++ tools/testing/selftests/bpf/network_helpers.c | 26 +- tools/testing/selftests/bpf/network_helpers.h | 3 + .../bpf/prog_tests/ip_check_defrag.c | 282 ++++++++++++++++++ .../bpf/prog_tests/netfilter_basic.c | 78 +++++ .../selftests/bpf/progs/ip_check_defrag.c | 104 +++++++ .../bpf/progs/test_netfilter_link_attach.c | 14 + 21 files changed, 868 insertions(+), 21 deletions(-) create mode 100755 tools/testing/selftests/bpf/generate_udp_fragments.py create mode 100644 tools/testing/selftests/bpf/ip_check_defrag_frags.h create mode 100644 tools/testing/selftests/bpf/prog_tests/ip_check_defrag.c create mode 100644 tools/testing/selftests/bpf/prog_tests/netfilter_basic.c create mode 100644 tools/testing/selftests/bpf/progs/ip_check_defrag.c create mode 100644 tools/testing/selftests/bpf/progs/test_netfilter_link_attach.c