netdev - RE: [PATCH v4 bpf-next 02/13] bpf: Enable bpf_skc_to_* sock casting helper to networking prog type

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 25 Sep 2020 07:21:22 -0700
From:   John Fastabend <john.fastabend@...il.com>
To:     Martin KaFai Lau <kafai@...com>, bpf@...r.kernel.org
Cc:     Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>, kernel-team@...com,
        Lorenz Bauer <lmb@...udflare.com>, netdev@...r.kernel.org
Subject: RE: [PATCH v4 bpf-next 02/13] bpf: Enable bpf_skc_to_* sock casting
 helper to networking prog type

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@...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@...il.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;
>  }
>