From: John Fastabend <john.fastabend@gmail.com>
To: Martin KaFai Lau <kafai@fb.com>, bpf@vger.kernel.org
Cc: Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
kernel-team@fb.com, Lorenz Bauer <lmb@cloudflare.com>,
netdev@vger.kernel.org
Subject: RE: [PATCH v4 bpf-next 02/13] bpf: Enable bpf_skc_to_* sock casting helper to networking prog type
Date: Fri, 25 Sep 2020 07:21:22 -0700 [thread overview]
Message-ID: <5f6dfce2db3e4_835ea20891@john-XPS-13-9370.notmuch> (raw)
In-Reply-To: <20200925000350.3855720-1-kafai@fb.com>
Martin KaFai Lau wrote:
> There is a constant need to add more fields into the bpf_tcp_sock
> for the bpf programs running at tc, sock_ops...etc.
>
> A current workaround could be to use bpf_probe_read_kernel(). However,
> other than making another helper call for reading each field and missing
> CO-RE, it is also not as intuitive to use as directly reading
> "tp->lsndtime" for example. While already having perfmon cap to do
> bpf_probe_read_kernel(), it will be much easier if the bpf prog can
> directly read from the tcp_sock.
>
> This patch tries to do that by using the existing casting-helpers
> bpf_skc_to_*() whose func_proto returns a btf_id. For example, the
> func_proto of bpf_skc_to_tcp_sock returns the btf_id of the
> kernel "struct tcp_sock".
>
> These helpers are also added to is_ptr_cast_function().
> It ensures the returning reg (BPF_REF_0) will also carries the ref_obj_id.
> That will keep the ref-tracking works properly.
>
> The bpf_skc_to_* helpers are made available to most of the bpf prog
> types in filter.c. The bpf_skc_to_* helpers will be limited by
> perfmon cap.
>
> This patch adds a ARG_PTR_TO_BTF_ID_SOCK_COMMON. The helper accepting
> this arg can accept a btf-id-ptr (PTR_TO_BTF_ID + &btf_sock_ids[BTF_SOCK_TYPE_SOCK_COMMON])
> or a legacy-ctx-convert-skc-ptr (PTR_TO_SOCK_COMMON). The bpf_skc_to_*()
> helpers are changed to take ARG_PTR_TO_BTF_ID_SOCK_COMMON such that
> they will accept pointer obtained from skb->sk.
>
> Instead of specifying both arg_type and arg_btf_id in the same func_proto
> which is how the current ARG_PTR_TO_BTF_ID does, the arg_btf_id of
> the new ARG_PTR_TO_BTF_ID_SOCK_COMMON is specified in the
> compatible_reg_types[] in verifier.c. The reason is the arg_btf_id is
> always the same. Discussion in this thread:
> https://lore.kernel.org/bpf/20200922070422.1917351-1-kafai@fb.com/
>
> The ARG_PTR_TO_BTF_ID_ part gives a clear expectation that the helper is
> expecting a PTR_TO_BTF_ID which could be NULL. This is the same
> behavior as the existing helper taking ARG_PTR_TO_BTF_ID.
>
> The _SOCK_COMMON part means the helper is also expecting the legacy
> SOCK_COMMON pointer.
>
> By excluding the _OR_NULL part, the bpf prog cannot call helper
> with a literal NULL which doesn't make sense in most cases.
> e.g. bpf_skc_to_tcp_sock(NULL) will be rejected. All PTR_TO_*_OR_NULL
> reg has to do a NULL check first before passing into the helper or else
> the bpf prog will be rejected. This behavior is nothing new and
> consistent with the current expectation during bpf-prog-load.
>
> [ ARG_PTR_TO_BTF_ID_SOCK_COMMON will be used to replace
> ARG_PTR_TO_SOCK* of other existing helpers later such that
> those existing helpers can take the PTR_TO_BTF_ID returned by
> the bpf_skc_to_*() helpers.
>
> The only special case is bpf_sk_lookup_assign() which can accept a
> literal NULL ptr. It has to be handled specially in another follow
> up patch if there is a need (e.g. by renaming ARG_PTR_TO_SOCKET_OR_NULL
> to ARG_PTR_TO_BTF_ID_SOCK_COMMON_OR_NULL). ]
>
> [ When converting the older helpers that take ARG_PTR_TO_SOCK* in
> the later patch, if the kernel does not support BTF,
> ARG_PTR_TO_BTF_ID_SOCK_COMMON will behave like ARG_PTR_TO_SOCK_COMMON
> because no reg->type could have PTR_TO_BTF_ID in this case.
>
> It is not a concern for the newer-btf-only helper like the bpf_skc_to_*()
> here though because these helpers must require BTF vmlinux to begin
> with. ]
>
> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
> ---
LGTM it took a bit of looking around to convince myself that
we have ret_type set to PTR_TO_SOCK_*_OR_NULL types in the sk lookup
helpers so that we force a null check before passing these into the
skc_to_* helpers here, but I didn't see any holes. Thanks.
Acked-by: John Fastabend <john.fastabend@gmail.com>
> @@ -4575,10 +4601,14 @@ static bool check_btf_id_ok(const struct bpf_func_proto *fn)
> {
> int i;
>
> - for (i = 0; i < ARRAY_SIZE(fn->arg_type); i++)
> + for (i = 0; i < ARRAY_SIZE(fn->arg_type); i++) {
> if (fn->arg_type[i] == ARG_PTR_TO_BTF_ID && !fn->arg_btf_id[i])
> return false;
>
> + if (fn->arg_type[i] != ARG_PTR_TO_BTF_ID && fn->arg_btf_id[i])
> + return false;
> + }
> +
I guess this case is harmless? If some other arg has a btf_id its setup
wrong, so nice to fail here I think.
> return true;
> }
>
next prev parent reply other threads:[~2020-09-25 14:21 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-25 0:03 [PATCH v4 bpf-next 00/13] bpf: Enable bpf_skc_to_* sock casting helper to networking prog type Martin KaFai Lau
2020-09-25 0:03 ` [PATCH v4 bpf-next 01/13] bpf: Move the PTR_TO_BTF_ID check to check_reg_type() Martin KaFai Lau
2020-09-25 8:22 ` Lorenz Bauer
2020-09-25 13:36 ` John Fastabend
2020-09-25 0:03 ` [PATCH v4 bpf-next 02/13] bpf: Enable bpf_skc_to_* sock casting helper to networking prog type Martin KaFai Lau
2020-09-25 8:26 ` Lorenz Bauer
2020-09-25 13:18 ` Martin KaFai Lau
2020-09-25 13:50 ` Lorenz Bauer
2020-09-25 15:47 ` Alexei Starovoitov
2020-09-25 14:21 ` John Fastabend [this message]
2020-09-25 0:03 ` [PATCH v4 bpf-next 03/13] bpf: Change bpf_sk_release and bpf_sk_*cgroup_id to accept ARG_PTR_TO_BTF_ID_SOCK_COMMON Martin KaFai Lau
2020-09-25 0:04 ` [PATCH v4 bpf-next 04/13] bpf: Change bpf_sk_storage_*() " Martin KaFai Lau
2020-09-25 0:04 ` [PATCH v4 bpf-next 05/13] bpf: Change bpf_tcp_*_syncookie " Martin KaFai Lau
2020-09-25 0:04 ` [PATCH v4 bpf-next 06/13] bpf: Change bpf_sk_assign " Martin KaFai Lau
2020-09-25 0:04 ` [PATCH v4 bpf-next 07/13] bpf: selftest: Add ref_tracking verifier test for bpf_skc casting Martin KaFai Lau
2020-09-25 8:30 ` Lorenz Bauer
2020-09-25 0:04 ` [PATCH v4 bpf-next 08/13] bpf: selftest: Move sock_fields test into test_progs Martin KaFai Lau
2020-09-25 0:04 ` [PATCH v4 bpf-next 09/13] bpf: selftest: Adapt sock_fields test to use skel and global variables Martin KaFai Lau
2020-09-25 0:04 ` [PATCH v4 bpf-next 10/13] bpf: selftest: Use network_helpers in the sock_fields test Martin KaFai Lau
2020-09-25 0:04 ` [PATCH v4 bpf-next 11/13] bpf: selftest: Use bpf_skc_to_tcp_sock() " Martin KaFai Lau
2020-09-25 0:04 ` [PATCH v4 bpf-next 12/13] bpf: selftest: Remove enum tcp_ca_state from bpf_tcp_helpers.h Martin KaFai Lau
2020-09-25 0:04 ` [PATCH v4 bpf-next 13/13] bpf: selftest: Add test_btf_skc_cls_ingress Martin KaFai Lau
2020-09-25 16:24 ` John Fastabend
2020-09-25 17:58 ` Martin KaFai Lau
2020-09-25 9:40 ` [PATCH v4 bpf-next 00/13] bpf: Enable bpf_skc_to_* sock casting helper to networking prog type Lorenz Bauer
2020-09-25 23:22 ` Alexei Starovoitov
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=5f6dfce2db3e4_835ea20891@john-XPS-13-9370.notmuch \
--to=john.fastabend@gmail.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=kafai@fb.com \
--cc=kernel-team@fb.com \
--cc=lmb@cloudflare.com \
--cc=netdev@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).