On Mon, Jun 22, 2020 at 11:39:11AM -0700, Andrey Ignatov wrote: > 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? It's tracing and pointers are accessed, so cap_perfmon.
