netdev - RE: [RFC PATCH v4 bpf-next 05/12] bpf: tcp: Add bpf_skops

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:   Mon, 03 Aug 2020 18:28:04 -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>,
        Eric Dumazet <edumazet@...gle.com>, kernel-team@...com,
        Lawrence Brakmo <brakmo@...com>,
        Neal Cardwell <ncardwell@...gle.com>, netdev@...r.kernel.org,
        Yuchung Cheng <ycheng@...gle.com>
Subject: RE: [RFC PATCH v4 bpf-next 05/12] bpf: tcp: Add
 bpf_skops_established()

Martin KaFai Lau wrote:
> In tcp_init_transfer(), it currently calls the bpf prog to give it a
> chance to handle the just "ESTABLISHED" event (e.g. do setsockopt
> on the newly established sk).  Right now, it is done by calling the
> general purpose tcp_call_bpf().
> 
> In the later patch, it also needs to pass the just-received skb which
> concludes the 3 way handshake. E.g. the SYNACK received at the active side.
> The bpf prog can then learn some specific header options written by the
> peer's bpf-prog and potentially do setsockopt on the newly established sk.
> Thus, instead of reusing the general purpose tcp_call_bpf(), a new function
> bpf_skops_established() is added to allow passing the "skb" to the bpf prog.
> The actual skb passing from bpf_skops_established() to the bpf prog
> will happen together in a later patch which has the necessary bpf pieces.
> 
> A "skb" arg is also added to tcp_init_transfer() such that
> it can then be passed to bpf_skops_established().
> 
> Calling the new bpf_skops_established() instead of tcp_call_bpf()
> should be a noop in this patch.

Yep, looks like a noop.

> 
> Signed-off-by: Martin KaFai Lau <kafai@...com>

Acked-by: John Fastabend <john.fastabend@...il.com>

[...]

>  
> +#ifdef CONFIG_CGROUP_BPF
> +static void bpf_skops_established(struct sock *sk, int bpf_op,
> +				  struct sk_buff *skb)


Small nit because its an RFC anyways.

Should we call this bpf_skops_fullsock(...) instead? Just a suggestion.

> +{
> +	struct bpf_sock_ops_kern sock_ops;
> +
> +	sock_owned_by_me(sk);
> +
> +	memset(&sock_ops, 0, offsetof(struct bpf_sock_ops_kern, temp));
> +	sock_ops.op = bpf_op;
> +	sock_ops.is_fullsock = 1;
> +	sock_ops.sk = sk;
> +	/* skb will be passed to the bpf prog in a later patch. */
> +
> +	BPF_CGROUP_RUN_PROG_SOCK_OPS(&sock_ops);
> +}