linux-kernel - Re: [PATCH bpf-next v2 1/3] bpf: Expose bpf_get_socket

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, 4 Dec 2020 11:47:48 -0800
From:   Martin KaFai Lau <kafai@...com>
To:     Florent Revest <revest@...omium.org>
CC:     <bpf@...r.kernel.org>, <ast@...nel.org>, <daniel@...earbox.net>,
        <andrii@...nel.org>, <kpsingh@...omium.org>, <revest@...gle.com>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH bpf-next v2 1/3] bpf: Expose bpf_get_socket_cookie to
 tracing programs

On Thu, Dec 03, 2020 at 10:33:28PM +0100, Florent Revest wrote:
> This creates a new helper proto because the existing
> bpf_get_socket_cookie_sock_proto has a ARG_PTR_TO_CTX argument and only
> works for BPF programs where the context is a sock.
> 
> This helper could also be useful to other BPF program types such as LSM.
> 
> Signed-off-by: Florent Revest <revest@...gle.com>
> ---
>  include/uapi/linux/bpf.h       | 7 +++++++
>  kernel/trace/bpf_trace.c       | 4 ++++
>  net/core/filter.c              | 7 +++++++
>  tools/include/uapi/linux/bpf.h | 7 +++++++
>  4 files changed, 25 insertions(+)
> 
> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index c3458ec1f30a..3e0e33c43998 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -1662,6 +1662,13 @@ union bpf_attr {
>   * 	Return
>   * 		A 8-byte long non-decreasing number.
>   *
> + * u64 bpf_get_socket_cookie(void *sk)
> + * 	Description
> + * 		Equivalent to **bpf_get_socket_cookie**\ () helper that accepts
> + * 		*sk*, but gets socket from a BTF **struct sock**.
> + * 	Return
> + * 		A 8-byte long non-decreasing number.
> + *
>   * u32 bpf_get_socket_uid(struct sk_buff *skb)
>   * 	Return
>   * 		The owner UID of the socket associated to *skb*. If the socket
> diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> index d255bc9b2bfa..14ad96579813 100644
> --- a/kernel/trace/bpf_trace.c
> +++ b/kernel/trace/bpf_trace.c
> @@ -1725,6 +1725,8 @@ raw_tp_prog_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
>  	}
>  }
>  
> +extern const struct bpf_func_proto bpf_get_socket_cookie_sock_tracing_proto;
> +
>  const struct bpf_func_proto *
>  tracing_prog_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
>  {
> @@ -1748,6 +1750,8 @@ tracing_prog_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
>  		return &bpf_sk_storage_get_tracing_proto;
>  	case BPF_FUNC_sk_storage_delete:
>  		return &bpf_sk_storage_delete_tracing_proto;
> +	case BPF_FUNC_get_socket_cookie:
> +		return &bpf_get_socket_cookie_sock_tracing_proto;
>  #endif
>  	case BPF_FUNC_seq_printf:
>  		return prog->expected_attach_type == BPF_TRACE_ITER ?
> diff --git a/net/core/filter.c b/net/core/filter.c
> index 2ca5eecebacf..177c4e5e529d 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -4631,6 +4631,13 @@ static const struct bpf_func_proto bpf_get_socket_cookie_sock_proto = {
>  	.arg1_type	= ARG_PTR_TO_CTX,
>  };
>  
> +const struct bpf_func_proto bpf_get_socket_cookie_sock_tracing_proto = {
> +	.func		= bpf_get_socket_cookie_sock,
> +	.gpl_only	= false,
> +	.ret_type	= RET_INTEGER,
> +	.arg1_type      = ARG_PTR_TO_BTF_ID_SOCK_COMMON,
In tracing where it gets a sk pointer, the sk could be NULL.
A NULL check is required in the helper. Please refer to
bpf_skc_to_tcp_sock[_proto] as an example.

This proto is in general also useful for non tracing context where
it can get a hold of a sk pointer. (e.g. another similar usage that will
have a hold on a sk pointer for BPF_PROG_TYPE_SK_REUSEPORT [0]).
In case if you don't need sleepable at this point as Daniel
mentioned in another thread.  Does it make sense to rename this
proto to something like bpf_get_socket_pointer_cookie_proto?

[0]: https://lore.kernel.org/bpf/20201201144418.35045-10-kuniyu@amazon.co.jp/