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 bpf-next v9 03/12] bpf: stop unsafely accessing TCP fields in bpf callbacks
Date: Mon, 10 Feb 2025 22:34:08 -0800 [thread overview]
Message-ID: <1ac825c7-e685-4363-ba9d-db0d983ce9f2@linux.dev> (raw)
In-Reply-To: <20250208103220.72294-4-kerneljasonxing@gmail.com>
On 2/8/25 2:32 AM, Jason Xing wrote:
> The "is_locked_tcp_sock" flag is added to indicate that the callback
> site has a tcp_sock locked.
It should mention that the later TX timestamping callbacks will not own the
lock. This is what this patch is primarily for. We know the background, but
future code readers may not. We will eventually become the readers of this patch
in a few years' time.
>
> Apply the new member is_locked_tcp_sock in the existing callbacks
It is hard to read "Apply the new member....". "Apply" could mean a few things.
"Set to 1" is clearer.
> where is_fullsock is set to 1 can stop UDP socket accessing struct
The UDP part is future proof. This set does not support UDP which has to be
clear in the commit message. This has been brought up before also.
> tcp_sock and stop TCP socket without sk lock protecting does the
> similar thing, or else it could be catastrophe leading to panic.
>
> To keep it simple, instead of distinguishing between read and write
> access, users aren't allowed all read/write access to the tcp_sock
> through the older bpf_sock_ops ctx. The new timestamping callbacks
> can use newer helpers to read everything from a sk (e.g. bpf_core_cast),
> so nothing is lost.
(Subject):
bpf: Prevent unsafe access to the sock fields in the BPF timestamping callback
(Why):
The subsequent patch will implement BPF TX timestamping. It will call the
sockops BPF program without holding the sock lock.
This breaks the current assumption that all sock ops programs will hold the sock
lock. The sock's fields of the uapi's bpf_sock_ops requires this assumption.
(What and How):
To address this,
a new "u8 is_locked_tcp_sock;" field is added. This patch sets it in the current
sock_ops callbacks. The "is_fullsock" test is then replaced by the
"is_locked_tcp_sock" test during sock_ops_convert_ctx_access().
The new TX timestamping callbacks added in the subsequent patch will not have
this set. This will prevent unsafe access from the new timestamping callbacks.
Potentially, we could allow read-only access. However, this would require
identifying which callback is read-safe-only and also requires additional BPF
instruction rewrites in the covert_ctx. Since the BPF program can always read
everything from a socket (e.g., by using bpf_core_cast), this patch keeps it
simple and disables all read and write access to any socket fields through the
bpf_sock_ops UAPI from the new TX timestamping callback.
Moreover, note that some of the fields in bpf_sock_ops are specific to tcp_sock,
and sock_ops currently only supports tcp_sock. In the future, UDP timestamping
will be added, which will also break this assumption. The same idea used in this
patch will be reused. Considering that the current sock_ops only supports
tcp_sock, the variable is named is_locked_"tcp"_sock.
next prev parent reply other threads:[~2025-02-11 6:34 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-08 10:32 [PATCH bpf-next v9 00/12] net-timestamp: bpf extension to equip applications transparently Jason Xing
2025-02-08 10:32 ` [PATCH bpf-next v9 01/12] bpf: add support for bpf_setsockopt() Jason Xing
2025-02-11 1:02 ` Martin KaFai Lau
2025-02-11 2:24 ` Jason Xing
2025-02-08 10:32 ` [PATCH bpf-next v9 02/12] bpf: prepare for timestamping callbacks use Jason Xing
2025-02-11 1:31 ` Martin KaFai Lau
2025-02-11 2:25 ` Jason Xing
2025-02-08 10:32 ` [PATCH bpf-next v9 03/12] bpf: stop unsafely accessing TCP fields in bpf callbacks Jason Xing
2025-02-11 6:34 ` Martin KaFai Lau [this message]
2025-02-11 8:08 ` Jason Xing
2025-02-08 10:32 ` [PATCH bpf-next v9 04/12] bpf: stop calling some sock_op BPF CALLs in new timestamping callbacks Jason Xing
2025-02-11 6:55 ` Martin KaFai Lau
2025-02-11 8:24 ` Jason Xing
2025-02-08 10:32 ` [PATCH bpf-next v9 05/12] net-timestamp: prepare for isolating two modes of SO_TIMESTAMPING Jason Xing
2025-02-08 10:32 ` [PATCH bpf-next v9 06/12] bpf: support SCM_TSTAMP_SCHED " Jason Xing
2025-02-11 7:12 ` Martin KaFai Lau
2025-02-11 7:31 ` Jason Xing
2025-02-08 10:32 ` [PATCH bpf-next v9 07/12] bpf: support sw SCM_TSTAMP_SND " Jason Xing
2025-02-08 10:32 ` [PATCH bpf-next v9 08/12] bpf: support hw " Jason Xing
2025-02-08 10:32 ` [PATCH bpf-next v9 09/12] bpf: support SCM_TSTAMP_ACK " Jason Xing
2025-02-08 17:54 ` Willem de Bruijn
2025-02-08 23:27 ` Jason Xing
2025-02-08 10:32 ` [PATCH bpf-next v9 10/12] bpf: add a new callback in tcp_tx_timestamp() Jason Xing
2025-02-08 10:32 ` [PATCH bpf-next v9 11/12] bpf: support selective sampling for bpf timestamping Jason Xing
2025-02-11 7:41 ` Martin KaFai Lau
2025-02-11 7:48 ` Jason Xing
2025-02-08 10:32 ` [PATCH bpf-next v9 12/12] selftests/bpf: add simple bpf tests in the tx path for timestamping feature Jason Xing
2025-02-11 8:05 ` Martin KaFai Lau
2025-02-11 11:37 ` Jason Xing
2025-02-10 23:37 ` [PATCH bpf-next v9 00/12] net-timestamp: bpf extension to equip applications transparently Martin KaFai Lau
2025-02-11 0:03 ` 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=1ac825c7-e685-4363-ba9d-db0d983ce9f2@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).