netdev - Re: [PATCH bpf-next] bpf: Allow setting SO_TIMESTAMPING* with bpf

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: <65a7f855821cc_6d500294d0@willemb.c.googlers.com.notmuch>
Date: Wed, 17 Jan 2024 10:55:01 -0500
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Martin KaFai Lau <martin.lau@...ux.dev>, 
 Jörn-Thorben Hinz <j-t.hinz@...mni.tu-berlin.de>
Cc: Willem de Bruijn <willemdebruijn.kernel@...il.com>, 
 Alexei Starovoitov <ast@...nel.org>, 
 Daniel Borkmann <daniel@...earbox.net>, 
 Andrii Nakryiko <andrii@...nel.org>, 
 "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>, 
 Arnd Bergmann <arnd@...db.de>, 
 Deepa Dinamani <deepa.kernel@...il.com>, 
 bpf@...r.kernel.org, 
 linux-kernel@...r.kernel.org, 
 netdev@...r.kernel.org, 
 linux-kselftest@...r.kernel.org
Subject: Re: [PATCH bpf-next] bpf: Allow setting SO_TIMESTAMPING* with
 bpf_setsockopt()

Martin KaFai Lau wrote:
> On 1/16/24 7:17 AM, Willem de Bruijn wrote:
> > Jörn-Thorben Hinz wrote:
> >> A BPF application, e.g., a TCP congestion control, might benefit from or
> >> even require precise (=hardware) packet timestamps. These timestamps are
> >> already available through __sk_buff.hwtstamp and
> >> bpf_sock_ops.skb_hwtstamp, but could not be requested: BPF programs were
> >> not allowed to set SO_TIMESTAMPING* on sockets.
> 
> This patch only uses the SOF_TIMESTAMPING_RX_HARDWARE in the selftest. How about 
> others? e.g. the SOF_TIMESTAMPING_TX_* that will affect the sk->sk_error_queue 
> which seems not good. If rx tstamp is useful, tx tstamp should be useful also?

Good point. Or should not be allowed to be set from BPF.

That significantly changes process behavior, e.g., by returning POLLERR.

> >>
> >> Enable BPF programs to actively request the generation of timestamps
> >> from a stream socket. The also required ioctl(SIOCSHWTSTAMP) on the
> >> network device must still be done separately, in user space.
> 
> hmm... so both ioctl(SIOCSHWTSTAMP) of the netdevice and the 
> SOF_TIMESTAMPING_RX_HARDWARE of the sk must be done?
> 
> I likely miss something. When skb is created in the driver rx path, the sk is 
> not known yet though. How the SOF_TIMESTAMPING_RX_HARDWARE of the sk affects the 
> skb_shinfo(skb)->hwtstamps?

Indeed it does not seem to do anything in the datapath.

Requesting SOF_TIMESTAMPING_RX_SOFTWARE will call net_enable_timestamp
to start timestamping packets.

But SOF_TIMESTAMPING_RX_HARDWARE does not so thing.

Drivers do use it in ethtool get_ts_info to signal hardware
capabilities. But those must be configured using the ioctl.

It is there more for consistency with the other timestamp recording
options, I suppose.