On Fri, Feb 24, 2023 at 3:49 AM Tero Kristo <tero.kristo@xxxxxxxxxxxxxxx> wrote:
>
>
> On 23/02/2023 19:46, Alexei Starovoitov wrote:
> > On Thu, Feb 23, 2023 at 5:23 AM Tero Kristo <tero.kristo@xxxxxxxxxxxxxxx> wrote:
> >> Hi,
> >>
> >> Some background first; on x86 platforms there is a free running TSC
> >> counter which can be used to generate extremely accurate profiling time
> >> stamps. Currently this can be used by BPF programs via hooking into perf
> >> subsystem and reading the value there; however this reduces the accuracy
> >> due to latency + jitter involved with long execution chain, and also the
> >> timebase gets converted into relative from the start of the execution of
> >> the program, instead of getting an absolute system level value.
> > Are you talking about rdtsc or some other counter?
> > Does it need an arch specific setup?
> Yes, this is rdtsc. TSC is setup automatically by the arch, but
> exporting it to BPF takes a few lines of arch specific code (I did use
> register_btf_kfunc_id_set() during init, under arch/x86/kernel/tsc.c.)
> >
> >> Now, I do have a pretty trivial patch (under internal review atm. at
> >> Intel) that adds an x86 platform specific bpf helper that can directly
> >> read this timestamp counter without relying to perf subsystem hooks.
> >>
> >> Do people have any feedback / insights on this list about addition of
> >> such platform specific BPF helper, basically thumbs up/down for adding
> >> such a thing? Currently I don't think there are any platform specific
> >> helpers in the kernel.
> > Right. That's one of the reasons we don't add new helpers anymore.
> > Please use kfunc instead. You can add it to:
> > arch/x86/net/bpf_jit_comp.c
> > like:
> > __bpf_kfunc u64 bpf_read_rdtsc(void)
> > { asm ("...
> > or to arch specific kernel module.
> >
> > Make sure to add selftests when you submit a patch.
>
> Ok, I can take a look at the selftest side if things nudge forward,
> however there is some internal pressure to ditch the whole idea of
> bpf_rdtsc() due to potential of side channel attacks by using BPF, and
> exploiting the accurate timer in the process. Any thoughts on that side?
> Using BPF requires root access nowadays so it is sort of on-par to
> out-of-tree kernel modules.
Can you elaborate on that security concern?
User space can do rdtsc, so not clear how doing the same in bpf prog
loaded by root makes any difference.
Unpriv bpf is pretty much non-existent.
bpf subsystem went root only long ago.
