Jason Xing wrote: > From: Jason Xing <kernelxing@xxxxxxxxxxx> > > A few weeks ago, I planned to extend SO_TIMESTMAMPING feature by using > tracepoint to print information (say, tstamp) so that we can > transparently equip applications with this feature and require no > modification in user side. > > Later, we discussed at netconf and agreed that we can use bpf for better > extension, which is mainly suggested by John Fastabend and Willem de > Bruijn. Many thanks here! So I post this series to see if we have a > better solution to extend. My feeling is BPF is a good place to provide > a way to add timestamping by administrators, without having to rebuild > applications. > > This approach mostly relies on existing SO_TIMESTAMPING feature, users > only needs to pass certain flags through bpf_setsocktop() to a separate > tsflags. For TX timestamps, they will be printed during generation > phase. For RX timestamps, we will wait for the moment when recvmsg() is > called. > > After this series, we could step by step implement more advanced > functions/flags already in SO_TIMESTAMPING feature for bpf extension. > > In this series, I only support TCP protocol which is widely used in > SO_TIMESTAMPING feature. > > --- > V2 > Link: https://lore.kernel.org/all/20241008095109.99918-1-kerneljasonxing@xxxxxxxxx/ > 1. Introduce tsflag requestors so that we are able to extend more in the > future. Besides, it enables TX flags for bpf extension feature separately > without breaking users. It is suggested by Vadim Fedorenko. > 2. introduce a static key to control the whole feature. (Willem) > 3. Open the gate of bpf_setsockopt for the SO_TIMESTAMPING feature in > some TX/RX cases, not all the cases. > > Note: > The main concern we've discussion in V1 thread is how to deal with the > applications using SO_TIMESTAMPING feature? In this series, I allow both > cases to happen at the same time, which indicates that even one > applications setting SO_TIMESTAMPING can still be traced through BPF > program. Please see patch [04/12]. This revision does not address the main concern. An administrator installed BPF program can affect results of a process using SO_TIMESTAMPING in ways that break it. My halfway suggestion was to only enable this if the process has not enabled timestamping on a socket, and to hard fail the application if it does enable it while BPF timestamping is active. You pushed back, entirely reasonably. But if anything we need a stronger method of isolation, not just ignore the issue.
