Message ID | 20211113142227.566439-1-me@ubique.spb.ru (mailing list archive) |
---|---|
Headers | show |
Series | Forbid bpf_ktime_get_coarse_ns and bpf_timer_* in tracing progs | expand |
On Sat, Nov 13, 2021 at 6:22 AM Dmitrii Banshchikov <me@ubique.spb.ru> wrote: > > Various locking issues are possible with bpf_ktime_get_coarse_ns() and > bpf_timer_* set of helpers. > > syzbot found a locking issue with bpf_ktime_get_coarse_ns() helper executed in > BPF_PROG_TYPE_PERF_EVENT prog type - [1]. The issue is possible because the > helper uses non fast version of time accessor that isn't safe for any context. > The helper was added because it provided performance benefits in comparison to > bpf_ktime_get_ns() helper. > > A similar locking issue is possible with bpf_timer_* set of helpers when used > in tracing progs. > > The solution is to restrict use of the helpers in tracing progs. > > In the [1] discussion it was stated that bpf_spin_lock related helpers shall > also be excluded for tracing progs. The verifier has a compatibility check > between a map and a program. If a tracing program tries to use a map which > value has struct bpf_spin_lock the verifier fails that is why bpf_spin_lock is > already restricted. > > Patch 1 restricts helpers > Patch 2 adds tests > > v1 -> v2: > * Limit the helpers via func proto getters instead of allowed callback > * Add note about helpers' restrictions to linux/bpf.h > * Add Fixes tag > * Remove extra \0 from btf_str_sec > * Beside asm tests add prog tests > * Trim CC > > 1. https://lore.kernel.org/all/00000000000013aebd05cff8e064@google.com/ Applied. Thanks
Alexei, On Sun, Nov 14 2021 at 10:38, Alexei Starovoitov wrote: > On Sat, Nov 13, 2021 at 6:22 AM Dmitrii Banshchikov <me@ubique.spb.ru> wrote: >> v1 -> v2: >> * Limit the helpers via func proto getters instead of allowed callback >> * Add note about helpers' restrictions to linux/bpf.h >> * Add Fixes tag >> * Remove extra \0 from btf_str_sec >> * Beside asm tests add prog tests >> * Trim CC >> >> 1. https://lore.kernel.org/all/00000000000013aebd05cff8e064@google.com/ > > Applied. Thanks applying crap faster than anyone involved can look at (hint: weekend) and without actually looking at the nonsense propagated by this 'hot fix' is what is going to cause long term maintaience trouble. Please revert the offending and obvious bogus comments in those commits. Thanks, tglx