[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200407170251.GE12003@kernel.org>
Date: Tue, 7 Apr 2020 14:02:51 -0300
From: Arnaldo Carvalho de Melo <arnaldo.melo@...il.com>
To: Alexey Budankov <alexey.budankov@...ux.intel.com>
Cc: Arnaldo Carvalho de Melo <arnaldo.melo@...il.com>,
Peter Zijlstra <peterz@...radead.org>,
Alexei Starovoitov <ast@...nel.org>,
Ingo Molnar <mingo@...hat.com>,
James Morris <jmorris@...ei.org>,
Namhyung Kim <namhyung@...nel.org>,
Serge Hallyn <serge@...lyn.com>, Jiri Olsa <jolsa@...hat.com>,
Song Liu <songliubraving@...com>,
Andi Kleen <ak@...ux.intel.com>,
Stephane Eranian <eranian@...gle.com>,
Igor Lubashev <ilubashe@...mai.com>,
Thomas Gleixner <tglx@...utronix.de>,
linux-kernel <linux-kernel@...r.kernel.org>,
"linux-security-module@...r.kernel.org"
<linux-security-module@...r.kernel.org>,
"selinux@...r.kernel.org" <selinux@...r.kernel.org>,
"intel-gfx@...ts.freedesktop.org" <intel-gfx@...ts.freedesktop.org>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
linux-man@...r.kernel.org
Subject: Re: [PATCH v8 00/12] Introduce CAP_PERFMON to secure system
performance monitoring and observability
Em Tue, Apr 07, 2020 at 07:52:56PM +0300, Alexey Budankov escreveu:
>
> On 07.04.2020 19:36, Arnaldo Carvalho de Melo wrote:
> > Em Tue, Apr 07, 2020 at 05:54:27PM +0300, Alexey Budankov escreveu:
> >> Could makes sense adding cap_ipc_lock to the binary to isolate from this:
> >> kernel/events/core.c: 6101
> >> if ((locked > lock_limit) && perf_is_paranoid() &&
> >> !capable(CAP_IPC_LOCK)) {
> >> ret = -EPERM;
> >> goto unlock;
> >> }
> > That did the trick, I'll update the documentation and include in my
> > "Committer testing" section:
> Looks like top mode somehow reaches perf mmap limit described here [1].
> Using -m option solves the issue avoiding cap_ipc_lock on my 8 cores machine:
> perf top -e cycles -m 1
So this would read better?
diff --git a/Documentation/admin-guide/perf-security.rst b/Documentation/admin-guide/perf-security.rst
index ed33682e26b0..d44dd24b0244 100644
--- a/Documentation/admin-guide/perf-security.rst
+++ b/Documentation/admin-guide/perf-security.rst
@@ -127,8 +127,8 @@ taken to create such groups of privileged Perf users.
::
- # setcap "cap_perfmon,cap_ipc_lock,cap_sys_ptrace,cap_syslog=ep" perf
- # setcap -v "cap_perfmon,cap_ipc_lock,cap_sys_ptrace,cap_syslog=ep" perf
+ # setcap "cap_perfmon,cap_sys_ptrace,cap_syslog=ep" perf
+ # setcap -v "cap_perfmon,cap_sys_ptrace,cap_syslog=ep" perf
perf: OK
# getcap perf
perf = cap_sys_ptrace,cap_syslog,cap_perfmon+ep
@@ -140,6 +140,10 @@ i.e.:
# setcap "38,cap_ipc_lock,cap_sys_ptrace,cap_syslog=ep" perf
+Note that you may need to have 'cap_ipc_lock' in the mix for tools such as
+'perf top', alternatively use 'perf top -m N', to reduce the memory that
+it uses for the perf ring buffer, see the memory allocation section below.
+
As a result, members of perf_users group are capable of conducting
performance monitoring and observability by using functionality of the
configured Perf tool executable that, when executes, passes perf_events
Powered by blists - more mailing lists