On 10.01.2020 17:02, Peter Zijlstra 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? Not really, this allows creating a kprobe using perf_event_open syscall that associates file descriptor with the kprobe [1]. Lifetime of that kprobe is equal to the lifetime of the file descriptor and the kprobe is not visible in tracefs: /sys/kernel/debug/tracing/kprobe_events > > 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. > ~Alexey [1] https://lore.kernel.org/lkml/20171206224518.3598254-1-songliubraving@xxxxxx/ _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
