On Fri, 10 Jan 2020 15:02:34 +0100 Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > On Thu, Jan 09, 2020 at 02:36:50PM +0300, Alexey Budankov wrote: > > On 08.01.2020 19:07, Peter Zijlstra wrote: > > > On Wed, Dec 18, 2019 at 12:25:35PM +0300, Alexey Budankov wrote: > > > >> diff --git a/kernel/events/core.c b/kernel/events/core.c > > >> index 059ee7116008..d9db414f2197 100644 > > >> --- a/kernel/events/core.c > > >> +++ b/kernel/events/core.c > > >> @@ -9056,7 +9056,7 @@ static int perf_kprobe_event_init(struct perf_event *event) > > >> if (event->attr.type != perf_kprobe.type) > > >> return -ENOENT; > > >> > > >> - if (!capable(CAP_SYS_ADMIN)) > > >> + if (!perfmon_capable()) > > >> return -EACCES; > > >> > > >> /* > > > > > > This one only allows attaching to already extant kprobes, right? It does > > > not allow creation of kprobes. > > > > This unblocks creation of local trace kprobes and uprobes by CAP_SYS_PERFMON > > privileged process, exactly the same as for CAP_SYS_ADMIN privileged process. > > I've no idea what you just said; it's just words. > > Again, this only allows attaching to previously created kprobes, it does > not allow creating kprobes, right? > > That is; I don't think CAP_SYS_PERFMON should be allowed to create > kprobes. > > As might be clear; I don't actually know what the user-ABI is for > creating kprobes. There are 2 ABIs nowadays, ftrace and ebpf. perf-probe uses ftrace interface to define new kprobe events, and those events are treated as completely same as tracepoint events. On the other hand, ebpf tries to define new probe event via perf_event interface. Above one is that interface. IOW, it creates new kprobe. Thank you, -- Masami Hiramatsu <mhiramat@xxxxxxxxxx> _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
