netdev - Re: [PATCH bpf-next 1/2] bpf: expose socket storage to BPF_PROG_TYPE_CGROUP

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]

Message-ID: <92a04281-8bfb-78ec-25b0-fa7adf8dd9c5@iogearbox.net>
Date:   Thu, 30 Jul 2020 00:52:21 +0200
From:   Daniel Borkmann <daniel@...earbox.net>
To:     Stanislav Fomichev <sdf@...gle.com>, netdev@...r.kernel.org,
        bpf@...r.kernel.org
Cc:     davem@...emloft.net, ast@...nel.org,
        Martin KaFai Lau <kafai@...com>
Subject: Re: [PATCH bpf-next 1/2] bpf: expose socket storage to
 BPF_PROG_TYPE_CGROUP_SOCK

On 7/29/20 2:31 AM, Stanislav Fomichev wrote:
> This lets us use socket storage from the following hooks:
> * BPF_CGROUP_INET_SOCK_CREATE
> * BPF_CGROUP_INET_SOCK_RELEASE
> * BPF_CGROUP_INET4_POST_BIND
> * BPF_CGROUP_INET6_POST_BIND
> 
> Using existing 'bpf_sk_storage_get_proto' doesn't work because
> second argument is ARG_PTR_TO_SOCKET. Even though
> BPF_PROG_TYPE_CGROUP_SOCK hooks operate on 'struct bpf_sock',
> the verifier still considers it as a PTR_TO_CTX.
> That's why I'm adding another 'bpf_sk_storage_get_cg_sock_proto'
> definition strictly for BPF_PROG_TYPE_CGROUP_SOCK which accepts
> ARG_PTR_TO_CTX which is really 'struct sock' for this program type.
> 
> Cc: Martin KaFai Lau <kafai@...com>
> Signed-off-by: Stanislav Fomichev <sdf@...gle.com>

Makes sense, both applied, thanks!

[...]
> diff --git a/net/core/filter.c b/net/core/filter.c
> index 29e3455122f7..7124f0fe6974 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -6187,6 +6187,7 @@ bool bpf_helper_changes_pkt_data(void *func)
>   }
>   
>   const struct bpf_func_proto bpf_event_output_data_proto __weak;
> +const struct bpf_func_proto bpf_sk_storage_get_cg_sock_proto __weak;
>   
>   static const struct bpf_func_proto *
>   sock_filter_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
> @@ -6219,6 +6220,8 @@ sock_filter_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
>   	case BPF_FUNC_get_cgroup_classid:
>   		return &bpf_get_cgroup_classid_curr_proto;
>   #endif
> +	case BPF_FUNC_sk_storage_get:
> +		return &bpf_sk_storage_get_cg_sock_proto;

Been wondering whether we need these for connect/sendmsg/etc hooks that operate
on sock_addr, but for those we have them already covered in sock_addr_func_proto()
therefore all good.

sock_addr_func_proto() also lists the BPF_FUNC_sk_storage_delete. Should we add
that one as well for sock_filter_func_proto()? Presumably create/release doesn't
make sense, but any use case for bind hook?

>   	default:
>   		return bpf_base_func_proto(func_id);
>   	}
>