netdev - Re: [PATCH net-next v5 03/15] bpf: introduce timestamp_used to allow UDP socket fetched in bpf prog

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: <CAL+tcoCpWs0f145_d+KLmAnuKhQ-83bANkiXXLHE_hoyhGj6Pw@mail.gmail.com>
Date: Sat, 18 Jan 2025 09:58:57 +0800
From: Jason Xing <kerneljasonxing@...il.com>
To: Martin KaFai Lau <martin.lau@...ux.dev>
Cc: davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org, 
	pabeni@...hat.com, dsahern@...nel.org, willemdebruijn.kernel@...il.com, 
	willemb@...gle.com, ast@...nel.org, daniel@...earbox.net, andrii@...nel.org, 
	eddyz87@...il.com, song@...nel.org, yonghong.song@...ux.dev, 
	john.fastabend@...il.com, kpsingh@...nel.org, sdf@...ichev.me, 
	haoluo@...gle.com, jolsa@...nel.org, horms@...nel.org, bpf@...r.kernel.org, 
	netdev@...r.kernel.org
Subject: Re: [PATCH net-next v5 03/15] bpf: introduce timestamp_used to allow
 UDP socket fetched in bpf prog

On Sat, Jan 18, 2025 at 9:42 AM Martin KaFai Lau <martin.lau@...ux.dev> wrote:
>
> On 1/15/25 5:12 PM, Jason Xing wrote:
> >>> Also, I need to set allow_direct_access to one as long as there is
> >>> "sock_ops.is_fullsock = 1;" in the existing callbacks.
> >> Only set allow_direct_access when the sk is fullsock in the "existing" sockops
> >> callback.
> > Only "existing"? Then how can the bpf program access those members of
> > the tcp socket structure in the current/new timestamping callbacks?
>
> There is at least one sk write:
>
>         case offsetof(struct bpf_sock_ops, sk_txhash):
>                 SOCK_OPS_GET_OR_SET_FIELD(sk_txhash, sk_txhash,
>                                          struct sock, type);
>
> afaict, the kernel always writes sk->sk_txhash with the sk lock held. The new
> timestamping callbacks cannot write because it does not hold the lock.

Surely, I will handle the sk_txhash case as you suggested :)

> Otherwise, it needs another flag in bpf_sock_ops_kern to say read only or not.
> imo, it is too complicated to be worth it.
>
> It is fine for the new timestamping callbacks not able to access the tcp_sock
> fields through the bpf_sock_ops. We are not losing anything. The accessible

Oh, that was my concern.

> tcp_sock fields through the bpf_sock_ops is limited and the  bpf_sock_ops api is
> pretty much frozen. The bpf prog should use the bpf_core_cast(skops->sk, struct
> tcp_sock). The future UDP timestamping support will likely need to use the
> bpf_core_cast anyway because we are not extending "struct bpf_sock_ops" for the
> udp_sock specific fields.

Thanks! Now I learned an interesting usage about bpf!

Thanks,
Jason