John Fastabend <john.fastabend@xxxxxxxxx> [Sat, 2020-06-20 20:27 -0700]: > Andrey Ignatov wrote: ... > > > > The feature is available only for CONFIG_DEBUG_INFO_BTF=y and gated by > > perfmon_capable() so that unpriv programs won't have access to bpf map > > fields. > > > > Signed-off-by: Andrey Ignatov <rdna@xxxxxx> > > --- > > include/linux/bpf.h | 9 ++ > > include/linux/bpf_verifier.h | 1 + > > kernel/bpf/arraymap.c | 3 + > > kernel/bpf/btf.c | 40 +++++++++ > > kernel/bpf/hashtab.c | 3 + > > kernel/bpf/verifier.c | 82 +++++++++++++++++-- > > .../selftests/bpf/verifier/map_ptr_mixing.c | 2 +- > > 7 files changed, 131 insertions(+), 9 deletions(-) > > > > diff --git a/include/linux/bpf.h b/include/linux/bpf.h > > index 07052d44bca1..1e1501ee53ce 100644 > > LGTM, but any reason not to allow this with bpf_capable() it looks > useful for building load balancers which might not be related to > CAP_PERFMON. Thanks for review John. I agree that this can be useful for many use-cases, incl. networking programs. Accessing a kernel struct looks like "tracing" kind of functionality to me (that's why CAP_PERFMON), but I'm not quite sure, and using bpf_capable() looks fine as well. Alexei, since you introduced CAP_BPF, could you clarify which cap is the right one to use here and why? > Otherwise, > > Acked-by: John Fastabend <john.fastabend@xxxxxxxxx> -- Andrey Ignatov
