bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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;
>  }
>  

  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] " 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 \
    --subject='RE: [PATCH v4 bpf-next 02/13] bpf: Enable bpf_skc_to_* sock casting helper to networking prog type' \
    /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

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).