netdev - RE: [PATCH 0/2] bpf, net: Allow setting SO

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: <64a33ce7b50d2_6520520875@john.notmuch>
Date: Mon, 03 Jul 2023 14:25:59 -0700
From: John Fastabend <john.fastabend@...il.com>
To: Jörn-Thorben Hinz <jthinz@...lbox.tu-berlin.de>, 
 bpf@...r.kernel.org, 
 linux-kernel@...r.kernel.org, 
 netdev@...r.kernel.org, 
 linux-kselftest@...r.kernel.org
Cc: Jörn-Thorben Hinz <jthinz@...lbox.tu-berlin.de>, 
 Alexei Starovoitov <ast@...nel.org>, 
 Daniel Borkmann <daniel@...earbox.net>, 
 Andrii Nakryiko <andrii@...nel.org>, 
 Martin KaFai Lau <martin.lau@...ux.dev>, 
 "David S. Miller" <davem@...emloft.net>, 
 Eric Dumazet <edumazet@...gle.com>, 
 Jakub Kicinski <kuba@...nel.org>, 
 Paolo Abeni <pabeni@...hat.com>, 
 Shuah Khan <shuah@...nel.org>, 
 Willem de Bruijn <willemb@...gle.com>, 
 Deepa Dinamani <deepa.kernel@...il.com>
Subject: RE: [PATCH 0/2] bpf, net: Allow setting SO_TIMESTAMPING* from BPF

Jörn-Thorben Hinz wrote:
> BPF applications, e.g., a TCP congestion control, might benefit from
> precise packet timestamps. These timestamps are already available in
> __sk_buff and bpf_sock_ops, but could not be requested: A BPF program
> was not allowed to set SO_TIMESTAMPING* on a socket. This change enables
> BPF programs to actively request the generation of timestamps from a
> stream socket.
> 
> To reuse the setget_sockopt BPF prog test for
> bpf_{get,set}sockopt(SO_TIMESTAMPING_NEW), also implement the missing
> getsockopt(SO_TIMESTAMPING_NEW) in the network stack.
> 
> I reckon the way I added getsockopt(SO_TIMESTAMPING_NEW) causes an API
> change: For existing users that set SO_TIMESTAMPING_NEW but queried
> SO_TIMESTAMPING_OLD afterwards, it would now look as if no timestamping
> flags have been set. Is this an acceptable change? If not, I’m happy to
> change getsockopt() to only be strict about the newly-implemented
> getsockopt(SO_TIMESTAMPING_NEW), or not distinguish between
> SO_TIMESTAMPING_NEW and SO_TIMESTAMPING_OLD at all.

Yeah, I think it would be best if we keep the old behavior and let
SO_TIMESTAMPING_OLD return timestamps for both new/old. It looks
like it should be relatively easy to implement?

Otherwise the series lgtm.

> 
> Jörn-Thorben Hinz (2):
>   net: Implement missing getsockopt(SO_TIMESTAMPING_NEW)
>   bpf: Allow setting SO_TIMESTAMPING* with bpf_setsockopt()
> 
>  include/uapi/linux/bpf.h                            | 3 ++-
>  net/core/filter.c                                   | 2 ++
>  net/core/sock.c                                     | 9 +++++++--
>  tools/include/uapi/linux/bpf.h                      | 3 ++-
>  tools/testing/selftests/bpf/progs/bpf_tracing_net.h | 2 ++
>  tools/testing/selftests/bpf/progs/setget_sockopt.c  | 4 ++++
>  6 files changed, 19 insertions(+), 4 deletions(-)
> 
> -- 
> 2.39.2
> 
>