From: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
To: "Toke Høiland-Jørgensen" <toke@redhat.com>
Cc: Lorenzo Bianconi <lorenzo@kernel.org>,
bpf@vger.kernel.org, netdev@vger.kernel.org, ast@kernel.org,
daniel@iogearbox.net, andrii@kernel.org, davem@davemloft.net,
kuba@kernel.org, edumazet@google.com, pabeni@redhat.com,
pablo@netfilter.org, fw@strlen.de,
netfilter-devel@vger.kernel.org, brouer@redhat.com,
memxor@gmail.com
Subject: Re: [PATCH v3 bpf-next 4/5] net: netfilter: add kfunc helper to add a new ct entry
Date: Wed, 18 May 2022 23:08:55 +0200 [thread overview]
Message-ID: <YoVgZ8OHlF/OpgHq@lore-desk> (raw)
In-Reply-To: <87y1yy8t6j.fsf@toke.dk>
[-- Attachment #1: Type: text/plain, Size: 5117 bytes --]
> Lorenzo Bianconi <lorenzo@kernel.org> writes:
>
> > Introduce bpf_xdp_ct_add and bpf_skb_ct_add kfunc helpers in order to
> > add a new entry to ct map from an ebpf program.
> > Introduce bpf_nf_ct_tuple_parse utility routine.
> >
> > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> > ---
> > net/netfilter/nf_conntrack_bpf.c | 212 +++++++++++++++++++++++++++----
> > 1 file changed, 189 insertions(+), 23 deletions(-)
> >
> > diff --git a/net/netfilter/nf_conntrack_bpf.c b/net/netfilter/nf_conntrack_bpf.c
> > index a9271418db88..3d31b602fdf1 100644
> > --- a/net/netfilter/nf_conntrack_bpf.c
> > +++ b/net/netfilter/nf_conntrack_bpf.c
> > @@ -55,41 +55,114 @@ enum {
> > NF_BPF_CT_OPTS_SZ = 12,
> > };
> >
> > -static struct nf_conn *__bpf_nf_ct_lookup(struct net *net,
> > - struct bpf_sock_tuple *bpf_tuple,
> > - u32 tuple_len, u8 protonum,
> > - s32 netns_id, u8 *dir)
> > +static int bpf_nf_ct_tuple_parse(struct bpf_sock_tuple *bpf_tuple,
> > + u32 tuple_len, u8 protonum, u8 dir,
> > + struct nf_conntrack_tuple *tuple)
> > {
> > - struct nf_conntrack_tuple_hash *hash;
> > - struct nf_conntrack_tuple tuple;
> > - struct nf_conn *ct;
> > + union nf_inet_addr *src = dir ? &tuple->dst.u3 : &tuple->src.u3;
> > + union nf_inet_addr *dst = dir ? &tuple->src.u3 : &tuple->dst.u3;
> > + union nf_conntrack_man_proto *sport = dir ? (void *)&tuple->dst.u
> > + : &tuple->src.u;
> > + union nf_conntrack_man_proto *dport = dir ? &tuple->src.u
> > + : (void *)&tuple->dst.u;
> >
> > if (unlikely(protonum != IPPROTO_TCP && protonum != IPPROTO_UDP))
> > - return ERR_PTR(-EPROTO);
> > - if (unlikely(netns_id < BPF_F_CURRENT_NETNS))
> > - return ERR_PTR(-EINVAL);
> > + return -EPROTO;
> > +
> > + memset(tuple, 0, sizeof(*tuple));
> >
> > - memset(&tuple, 0, sizeof(tuple));
> > switch (tuple_len) {
> > case sizeof(bpf_tuple->ipv4):
> > - tuple.src.l3num = AF_INET;
> > - tuple.src.u3.ip = bpf_tuple->ipv4.saddr;
> > - tuple.src.u.tcp.port = bpf_tuple->ipv4.sport;
> > - tuple.dst.u3.ip = bpf_tuple->ipv4.daddr;
> > - tuple.dst.u.tcp.port = bpf_tuple->ipv4.dport;
> > + tuple->src.l3num = AF_INET;
> > + src->ip = bpf_tuple->ipv4.saddr;
> > + sport->tcp.port = bpf_tuple->ipv4.sport;
> > + dst->ip = bpf_tuple->ipv4.daddr;
> > + dport->tcp.port = bpf_tuple->ipv4.dport;
> > break;
> > case sizeof(bpf_tuple->ipv6):
> > - tuple.src.l3num = AF_INET6;
> > - memcpy(tuple.src.u3.ip6, bpf_tuple->ipv6.saddr, sizeof(bpf_tuple->ipv6.saddr));
> > - tuple.src.u.tcp.port = bpf_tuple->ipv6.sport;
> > - memcpy(tuple.dst.u3.ip6, bpf_tuple->ipv6.daddr, sizeof(bpf_tuple->ipv6.daddr));
> > - tuple.dst.u.tcp.port = bpf_tuple->ipv6.dport;
> > + tuple->src.l3num = AF_INET6;
> > + memcpy(src->ip6, bpf_tuple->ipv6.saddr, sizeof(bpf_tuple->ipv6.saddr));
> > + sport->tcp.port = bpf_tuple->ipv6.sport;
> > + memcpy(dst->ip6, bpf_tuple->ipv6.daddr, sizeof(bpf_tuple->ipv6.daddr));
> > + dport->tcp.port = bpf_tuple->ipv6.dport;
> > break;
> > default:
> > - return ERR_PTR(-EAFNOSUPPORT);
> > + return -EAFNOSUPPORT;
> > }
> > + tuple->dst.protonum = protonum;
> > + tuple->dst.dir = dir;
> > +
> > + return 0;
> > +}
> >
> > - tuple.dst.protonum = protonum;
> > +struct nf_conn *
> > +__bpf_nf_ct_alloc_entry(struct net *net, struct bpf_sock_tuple *bpf_tuple,
> > + u32 tuple_len, u8 protonum, s32 netns_id, u32 timeout)
> > +{
> > + struct nf_conntrack_tuple otuple, rtuple;
> > + struct nf_conn *ct;
> > + int err;
> > +
> > + if (unlikely(netns_id < BPF_F_CURRENT_NETNS))
> > + return ERR_PTR(-EINVAL);
> > +
> > + err = bpf_nf_ct_tuple_parse(bpf_tuple, tuple_len, protonum,
> > + IP_CT_DIR_ORIGINAL, &otuple);
> > + if (err < 0)
> > + return ERR_PTR(err);
> > +
> > + err = bpf_nf_ct_tuple_parse(bpf_tuple, tuple_len, protonum,
> > + IP_CT_DIR_REPLY, &rtuple);
> > + if (err < 0)
> > + return ERR_PTR(err);
> > +
> > + if (netns_id >= 0) {
> > + net = get_net_ns_by_id(net, netns_id);
> > + if (unlikely(!net))
> > + return ERR_PTR(-ENONET);
> > + }
> > +
> > + ct = nf_conntrack_alloc(net, &nf_ct_zone_dflt, &otuple, &rtuple,
> > + GFP_ATOMIC);
> > + if (IS_ERR(ct))
> > + goto out;
> > +
> > + ct->timeout = timeout * HZ + jiffies;
> > + ct->status |= IPS_CONFIRMED;
> > +
> > + memset(&ct->proto, 0, sizeof(ct->proto));
> > + if (protonum == IPPROTO_TCP)
> > + ct->proto.tcp.state = TCP_CONNTRACK_ESTABLISHED;
>
> Hmm, isn't it a bit limiting to hard-code this to ESTABLISHED
> connections? Presumably for TCP you'd want to use this when you see a
> SYN and then rely on conntrack to help with the subsequent state
> tracking for when the SYN-ACK comes back? What's the usecase for
> creating an entry in ESTABLISHED state, exactly?
I guess we can even add a parameter and pass the state from the caller.
I was not sure if it is mandatory.
Regards,
Lorenzo
>
> (Of course, we'd need to be able to update the state as well, then...)
>
> -Toke
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2022-05-18 21:09 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-18 10:43 [PATCH v3 bpf-next 0/5] net: netfilter: add kfunc helper to update ct timeout Lorenzo Bianconi
2022-05-18 10:43 ` [PATCH v3 bpf-next 1/5] bpf: Add support for forcing kfunc args to be referenced Lorenzo Bianconi
2022-05-18 17:58 ` Yonghong Song
2022-05-18 18:06 ` Kumar Kartikeya Dwivedi
2022-05-18 18:23 ` Yonghong Song
2022-05-18 10:43 ` [PATCH v3 bpf-next 2/5] selftests/bpf: Add verifier selftests for forced kfunc ref args Lorenzo Bianconi
2022-05-18 18:25 ` Yonghong Song
2022-05-18 10:43 ` [PATCH v3 bpf-next 3/5] net: netfilter: add kfunc helper to update ct timeout Lorenzo Bianconi
2022-05-18 20:42 ` Toke Høiland-Jørgensen
2022-05-18 10:43 ` [PATCH v3 bpf-next 4/5] net: netfilter: add kfunc helper to add a new ct entry Lorenzo Bianconi
2022-05-18 20:47 ` Toke Høiland-Jørgensen
2022-05-18 21:08 ` Lorenzo Bianconi [this message]
2022-05-18 22:14 ` Alexei Starovoitov
2022-05-18 22:43 ` Kumar Kartikeya Dwivedi
2022-05-19 10:45 ` Toke Høiland-Jørgensen
2022-05-19 11:23 ` Kumar Kartikeya Dwivedi
2022-05-19 17:00 ` Yonghong Song
2022-05-19 17:10 ` Kumar Kartikeya Dwivedi
2022-05-19 2:06 ` kernel test robot
2022-05-18 10:43 ` [PATCH v3 bpf-next 5/5] selftests/bpf: add selftest for bpf_xdp_ct_add and bpf_ct_refresh_timeout kfunc Lorenzo Bianconi
2022-05-18 18:55 ` Yonghong Song
2022-05-18 20:38 ` Lorenzo Bianconi
2022-05-20 22:04 ` Andrii Nakryiko
2022-05-21 9:56 ` Lorenzo Bianconi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YoVgZ8OHlF/OpgHq@lore-desk \
--to=lorenzo.bianconi@redhat.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brouer@redhat.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=fw@strlen.de \
--cc=kuba@kernel.org \
--cc=lorenzo@kernel.org \
--cc=memxor@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pablo@netfilter.org \
--cc=toke@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.