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]

Date: Tue, 4 Jul 2023 18:11:51 +0200
From: Jörn-Thorben Hinz <jthinz@...lbox.tu-berlin.de>
To: John Fastabend <john.fastabend@...il.com>, <bpf@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <netdev@...r.kernel.org>,
	<linux-kselftest@...r.kernel.org>
CC: 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

Thank you for the feedback.

Just noticed I missed the “bpf-next” designation in the subject. Will
add that in v2.

On Mon, 2023-07-03 at 14:25 -0700, John Fastabend wrote:
> 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?
Alright, I guessed that would be preferred.

Yes, if there is no objection to making the added
getsockopt(SO_TIMESTAMPING_NEW) this tiny bit more “strict”, it’s just
a matter of modifying the if inserted in sk_getsockopt(). (And, well,
in the other case I would even remove this if.)

> 
> Otherwise the series lgtm.
Great, thanks.

> 
> > 
> > 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
> >