From: Masami Hiramatsu <mhiramat@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
Song Liu <songliubraving@fb.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Will Deacon <will.deacon@arm.com>,
Alexei Starovoitov <ast@kernel.org>,
Stephane Eranian <eranian@google.com>,
"james.bottomley@hansenpartnership.com"
<james.bottomley@hansenpartnership.com>,
Paul Mackerras <paulus@samba.org>, Jiri Olsa <jolsa@redhat.com>,
Andi Kleen <ak@linux.intel.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Igor Lubashev <ilubashe@akamai.com>,
James Morris <jmorris@namei.org>, Ingo Molnar <mingo@redhat.com>,
oprofile-list@lists.sf.net, Serge Hallyn <serge@hallyn.com>,
Robert Richter <rric@kernel.org>,
Kees Cook <keescook@chromium.org>, Jann Horn <jannh@google.com>,
"selinux@vger.kernel.org" <selinux@vger.kernel.org>,
"intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedes>
Subject: Re: [PATCH v4 2/9] perf/core: open access for CAP_SYS_PERFMON privileged process
Date: Sat, 11 Jan 2020 00:52:13 +0900 [thread overview]
Message-ID: <20200111005213.6dfd98fb36ace098004bde0e@kernel.org> (raw)
In-Reply-To: <20200110140234.GO2844@hirez.programming.kicks-ass.net>
On Fri, 10 Jan 2020 15:02:34 +0100
Peter Zijlstra <peterz@infradead.org> 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@kernel.org>
next prev parent reply other threads:[~2020-01-10 15:52 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-18 9:16 [PATCH v4 0/7] Introduce CAP_SYS_PERFMON to secure system performance monitoring and observability Alexey Budankov
2019-12-18 9:24 ` [PATCH v4 1/9] capabilities: introduce CAP_SYS_PERFMON to kernel and user space Alexey Budankov
2019-12-18 19:56 ` Stephen Smalley
2019-12-28 3:53 ` Serge E. Hallyn
2020-01-13 20:25 ` Song Liu
2019-12-18 9:25 ` [PATCH v4 2/9] perf/core: open access for CAP_SYS_PERFMON privileged process Alexey Budankov
2020-01-08 16:07 ` Peter Zijlstra
2020-01-09 11:36 ` Alexey Budankov
2020-01-10 14:02 ` Peter Zijlstra
2020-01-10 15:52 ` Masami Hiramatsu [this message]
2020-01-10 16:45 ` Arnaldo Carvalho de Melo
2020-01-10 23:47 ` Masami Hiramatsu
2020-01-11 0:23 ` Song Liu
[not found] ` <5e191833.1c69fb81.8bc25.a88c@mx.google.com>
2020-01-12 1:44 ` Masami Hiramatsu
2020-01-10 16:41 ` Alexey Budankov
2020-01-10 17:34 ` Alexey Budankov
2019-12-18 9:26 ` [PATCH v4 3/9] perf tool: extend Perf tool with CAP_SYS_PERFMON capability support Alexey Budankov
2019-12-18 9:27 ` [PATCH v4 4/9] drm/i915/perf: open access for CAP_SYS_PERFMON privileged process Alexey Budankov
2019-12-19 9:10 ` Lionel Landwerlin
2019-12-18 9:28 ` [PATCH v4 5/9] trace/bpf_trace: " Alexey Budankov
2020-01-13 20:47 ` Song Liu
2019-12-18 9:28 ` [PATCH v4 6/9] powerpc/perf: " Alexey Budankov
2019-12-18 9:29 ` [PATCH v4 7/9] parisc/perf: " Alexey Budankov
2020-01-27 8:52 ` Helge Deller
2019-12-18 9:30 ` [PATCH v4 8/9] drivers/perf: " Alexey Budankov
2020-01-17 10:51 ` Will Deacon
2020-01-17 21:33 ` Alexey Budankov
2019-12-18 9:31 ` [PATCH v4 9/9] drivers/oprofile: " Alexey Budankov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200111005213.6dfd98fb36ace098004bde0e@kernel.org \
--to=mhiramat@kernel.org \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=ast@kernel.org \
--cc=benh@kernel.crashing.org \
--cc=eranian@google.com \
--cc=ilubashe@akamai.com \
--cc=intel-gfx@lists.freedes \
--cc=james.bottomley@hansenpartnership.com \
--cc=jannh@google.com \
--cc=jmorris@namei.org \
--cc=jolsa@redhat.com \
--cc=keescook@chromium.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=mpe@ellerman.id.au \
--cc=oprofile-list@lists.sf.net \
--cc=paulus@samba.org \
--cc=peterz@infradead.org \
--cc=rric@kernel.org \
--cc=selinux@vger.kernel.org \
--cc=serge@hallyn.com \
--cc=songliubraving@fb.com \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).