All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin KaFai Lau <martin.lau@linux.dev>
To: Jason Xing <kerneljasonxing@gmail.com>
Cc: davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
	pabeni@redhat.com, dsahern@kernel.org,
	willemdebruijn.kernel@gmail.com, willemb@google.com,
	ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
	eddyz87@gmail.com, song@kernel.org, yonghong.song@linux.dev,
	john.fastabend@gmail.com, kpsingh@kernel.org, sdf@fomichev.me,
	haoluo@google.com, jolsa@kernel.org, horms@kernel.org,
	bpf@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH net-next v5 05/15] net-timestamp: add strict check in some BPF calls
Date: Wed, 15 Jan 2025 13:48:37 -0800	[thread overview]
Message-ID: <ca852e76-2627-4e07-8005-34168271bf12@linux.dev> (raw)
In-Reply-To: <20250112113748.73504-6-kerneljasonxing@gmail.com>

On 1/12/25 3:37 AM, Jason Xing wrote:
> In the next round, we will support the UDP proto for SO_TIMESTAMPING
> bpf extension, so we need to ensure there is no safety problem.
> 
> Signed-off-by: Jason Xing <kerneljasonxing@gmail.com>
> ---
>   net/core/filter.c | 9 +++++++--
>   1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/net/core/filter.c b/net/core/filter.c
> index 0e915268db5f..517f09aabc92 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -5571,7 +5571,7 @@ static int __bpf_getsockopt(struct sock *sk, int level, int optname,
>   static int _bpf_getsockopt(struct sock *sk, int level, int optname,
>   			   char *optval, int optlen)
>   {
> -	if (sk_fullsock(sk))
> +	if (sk_fullsock(sk) && optname != SK_BPF_CB_FLAGS)
>   		sock_owned_by_me(sk);
>   	return __bpf_getsockopt(sk, level, optname, optval, optlen);
>   }
> @@ -5776,6 +5776,7 @@ BPF_CALL_5(bpf_sock_ops_getsockopt, struct bpf_sock_ops_kern *, bpf_sock,
>   	   int, level, int, optname, char *, optval, int, optlen)
>   {
>   	if (IS_ENABLED(CONFIG_INET) && level == SOL_TCP &&
> +	    bpf_sock->sk->sk_protocol == IPPROTO_TCP &&
>   	    optname >= TCP_BPF_SYN && optname <= TCP_BPF_SYN_MAC) {
>   		int ret, copy_len = 0;
>   		const u8 *start;
> @@ -5817,7 +5818,8 @@ BPF_CALL_2(bpf_sock_ops_cb_flags_set, struct bpf_sock_ops_kern *, bpf_sock,
>   	struct sock *sk = bpf_sock->sk;
>   	int val = argval & BPF_SOCK_OPS_ALL_CB_FLAGS;
>   
> -	if (!IS_ENABLED(CONFIG_INET) || !sk_fullsock(sk))
> +	if (!IS_ENABLED(CONFIG_INET) || !sk_fullsock(sk) ||
> +	    sk->sk_protocol != IPPROTO_TCP)
>   		return -EINVAL;
>   
>   	tcp_sk(sk)->bpf_sock_ops_cb_flags = val;
> @@ -7626,6 +7628,9 @@ BPF_CALL_4(bpf_sock_ops_load_hdr_opt, struct bpf_sock_ops_kern *, bpf_sock,
>   	u8 search_kind, search_len, copy_len, magic_len;
>   	int ret;
>   
> +	if (bpf_sock->op != SK_BPF_CB_FLAGS)

SK_BPF_CB_FLAGS is not an op enum, so the check is incorrect. It does break the 
existing test.

./test_progs -t tcp_hdr_options
WARNING! Selftests relying on bpf_testmod.ko will be skipped.
#402/1   tcp_hdr_options/simple_estab:FAIL
#402/2   tcp_hdr_options/no_exprm_estab:FAIL
#402/3   tcp_hdr_options/syncookie_estab:FAIL
#402/4   tcp_hdr_options/fastopen_estab:FAIL
#402/5   tcp_hdr_options/fin:FAIL
#402/6   tcp_hdr_options/misc:FAIL
#402     tcp_hdr_options:FAIL
#402/1   tcp_hdr_options/simple_estab:FAIL
#402/2   tcp_hdr_options/no_exprm_estab:FAIL
#402/3   tcp_hdr_options/syncookie_estab:FAIL
#402/4   tcp_hdr_options/fastopen_estab:FAIL
#402/5   tcp_hdr_options/fin:FAIL
#402/6   tcp_hdr_options/misc:FAIL
#402     tcp_hdr_options:FAIL


Many changes of this set is in bpf and the newly added selftest is also a bpf 
prog, all bpf selftests should be run before posting. 
(Documentation/bpf/bpf_devel_QA.rst)

The bpf CI can automatically pick it up and get an auto email on breakage like 
this if the set is tagged to bpf-next. We can figure out where to land the set 
later (bpf-next/net or net-next/main) when it is ready.

All these changes also need a test in selftests/bpf. For example, I expect there 
is a test to ensure calling these bpf helpers from the new tstamp callback will 
get a negative errno value.

For patch 4 and patch 5, I would suggest keeping it simple to only check for 
bpf_sock->op for the helpers that make tcp_sock and/or locked sk assumption.
Something like this on top of your patch. Untested:

diff --git i/net/core/filter.c w/net/core/filter.c
index 517f09aabc92..ccb13b61c528 100644
--- i/net/core/filter.c
+++ w/net/core/filter.c
@@ -7620,6 +7620,11 @@ static const u8 *bpf_search_tcp_opt(const u8 *op, const 
u8 *opend,
  	return ERR_PTR(-ENOMSG);
  }

+static bool is_locked_tcp_sock_ops(struct bpf_sock_ops_kern *bpf_sock)
+{
+	return bpf_sock->op <= BPF_SOCK_OPS_WRITE_HDR_OPT_CB;
+}
+
  BPF_CALL_4(bpf_sock_ops_load_hdr_opt, struct bpf_sock_ops_kern *, bpf_sock,
  	   void *, search_res, u32, len, u64, flags)
  {
@@ -7628,8 +7633,8 @@ BPF_CALL_4(bpf_sock_ops_load_hdr_opt, struct 
bpf_sock_ops_kern *, bpf_sock,
  	u8 search_kind, search_len, copy_len, magic_len;
  	int ret;

-	if (bpf_sock->op != SK_BPF_CB_FLAGS)
-		return -EINVAL;
+	if (!is_locked_tcp_sock_ops(bpf_sock))
+		return -EOPNOTSUPP;

  	/* 2 byte is the minimal option len except TCPOPT_NOP and
  	 * TCPOPT_EOL which are useless for the bpf prog to learn


> +		return -EINVAL;
> +
>   	/* 2 byte is the minimal option len except TCPOPT_NOP and
>   	 * TCPOPT_EOL which are useless for the bpf prog to learn
>   	 * and this helper disallow loading them also.


  parent reply	other threads:[~2025-01-15 21:48 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-12 11:37 [PATCH net-next v5 00/15] net-timestamp: bpf extension to equip applications transparently Jason Xing
2025-01-12 11:37 ` [PATCH net-next v5 01/15] net-timestamp: add support for bpf_setsockopt() Jason Xing
2025-01-12 14:49   ` kernel test robot
2025-01-13  0:11     ` Jason Xing
2025-01-13  7:32       ` Jason Xing
2025-01-14 23:20   ` Martin KaFai Lau
2025-01-14 23:29     ` Jason Xing
2025-01-12 11:37 ` [PATCH net-next v5 02/15] net-timestamp: prepare for bpf prog use Jason Xing
2025-01-14 23:39   ` Martin KaFai Lau
2025-01-15  0:09     ` Jason Xing
2025-01-15  0:15       ` Jason Xing
2025-01-15  0:26         ` Martin KaFai Lau
2025-01-15  0:37           ` Jason Xing
2025-01-15  0:43             ` Jason Xing
2025-01-12 11:37 ` [PATCH net-next v5 03/15] bpf: introduce timestamp_used to allow UDP socket fetched in bpf prog Jason Xing
2025-01-15  1:17   ` Martin KaFai Lau
2025-01-15  2:28     ` Jason Xing
2025-01-15  2:54       ` Jason Xing
2025-01-16  0:51         ` Martin KaFai Lau
2025-01-16  1:12           ` Jason Xing
2025-01-18  1:42             ` Martin KaFai Lau
2025-01-18  1:58               ` Jason Xing
2025-01-18  2:16                 ` Martin KaFai Lau
2025-01-18  2:37                   ` Jason Xing
2025-01-12 11:37 ` [PATCH net-next v5 04/15] net-timestamp: support SK_BPF_CB_FLAGS only in bpf_sock_ops_setsockopt Jason Xing
2025-01-15 21:22   ` Martin KaFai Lau
2025-01-15 23:26     ` Jason Xing
2025-01-12 11:37 ` [PATCH net-next v5 05/15] net-timestamp: add strict check in some BPF calls Jason Xing
2025-01-12 14:37   ` kernel test robot
2025-01-13  0:28     ` Jason Xing
2025-01-15 21:48   ` Martin KaFai Lau [this message]
2025-01-15 23:32     ` Jason Xing
2025-01-18  2:15       ` Martin KaFai Lau
2025-01-18  6:28         ` Jason Xing
2025-01-17 10:18   ` kernel test robot
2025-01-12 11:37 ` [PATCH net-next v5 06/15] net-timestamp: prepare for isolating two modes of SO_TIMESTAMPING Jason Xing
2025-01-15 22:11   ` Martin KaFai Lau
2025-01-15 23:50     ` Jason Xing
2025-01-12 11:37 ` [PATCH net-next v5 07/15] net-timestamp: support SCM_TSTAMP_SCHED for bpf extension Jason Xing
2025-01-15 22:32   ` Martin KaFai Lau
2025-01-15 23:57     ` Jason Xing
2025-01-12 11:37 ` [PATCH net-next v5 08/15] net-timestamp: support sw SCM_TSTAMP_SND " Jason Xing
2025-01-15 22:48   ` Martin KaFai Lau
2025-01-15 23:56     ` Jason Xing
2025-01-18  0:46       ` Martin KaFai Lau
2025-01-18  1:43         ` Jason Xing
2025-01-19 13:38           ` Jason Xing
2025-01-12 11:37 ` [PATCH net-next v5 09/15] net-timestamp: support SCM_TSTAMP_ACK " Jason Xing
2025-01-15 23:02   ` Martin KaFai Lau
2025-01-12 11:37 ` [PATCH net-next v5 10/15] net-timestamp: support hw SCM_TSTAMP_SND " Jason Xing
2025-01-12 11:37 ` [PATCH net-next v5 11/15] net-timestamp: support export skb to the userspace Jason Xing
2025-01-15 23:05   ` Martin KaFai Lau
2025-01-15 23:59     ` Jason Xing
2025-01-12 11:37 ` [PATCH net-next v5 12/15] net-timestamp: make TCP tx timestamp bpf extension work Jason Xing
2025-01-12 11:37 ` [PATCH net-next v5 13/15] net-timestamp: support tcp_sendmsg for bpf extension Jason Xing
2025-01-16  0:03   ` Martin KaFai Lau
2025-01-16  0:41     ` Jason Xing
2025-01-16  1:18       ` Martin KaFai Lau
2025-01-16  1:22         ` Jason Xing
2025-01-12 11:37 ` [PATCH net-next v5 14/15] net-timestamp: introduce cgroup lock to avoid affecting non-bpf cases Jason Xing
2025-01-12 11:37 ` [PATCH net-next v5 15/15] bpf: add simple bpf tests in the tx path for so_timestamping feature Jason Xing

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=ca852e76-2627-4e07-8005-34168271bf12@linux.dev \
    --to=martin.lau@linux.dev \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=eddyz87@gmail.com \
    --cc=edumazet@google.com \
    --cc=haoluo@google.com \
    --cc=horms@kernel.org \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kerneljasonxing@gmail.com \
    --cc=kpsingh@kernel.org \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=sdf@fomichev.me \
    --cc=song@kernel.org \
    --cc=willemb@google.com \
    --cc=willemdebruijn.kernel@gmail.com \
    --cc=yonghong.song@linux.dev \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.