From: Alexey Budankov <alexey.budankov@linux.intel.com> To: Will Deacon <will@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org>, Arnaldo Carvalho de Melo <acme@kernel.org>, Ingo Molnar <mingo@redhat.com>, "jani.nikula@linux.intel.com" <jani.nikula@linux.intel.com>, "joonas.lahtinen@linux.intel.com" <joonas.lahtinen@linux.intel.com>, "rodrigo.vivi@intel.com" <rodrigo.vivi@intel.com>, Alexei Starovoitov <ast@kernel.org>, Benjamin Herrenschmidt <benh@kernel.crashing.org>, Paul Mackerras <paulus@samba.org>, Michael Ellerman <mpe@ellerman.id.au>, "james.bottomley@hansenpartnership.com" <james.bottomley@hansenpartnership.com>, Serge Hallyn <serge@hallyn.com>, James Morris <jmorris@namei.org>, Will Deacon <will.deacon@arm.com>, Mark Rutland <mark.rutland@arm.com>, Casey Schaufler <casey@schaufler-ca.com>, Robert Richter <rric@kernel.org>, Song Liu <songliubraving@fb.com>, Alexander Shishkin <alexander.shishkin@linux.intel.com>, Stephane Eranian <eranian@google.com>, Jiri Olsa <jolsa@redhat.com>, Andi Kleen <ak@linux.intel.com>, Igor Lubashev <ilubashe@akamai.com>, linux-kernel <linux-kernel@vger.kernel.org>, Kees Cook <keescook@chromium.org>, Jann Horn <jannh@google.com>, linux-arm-kernel@lists.infradead.org, Namhyung Kim <namhyung@kernel.org>, Thomas Gleixner <tglx@linutronix.de> Subject: Re: [PATCH v4 8/9] drivers/perf: open access for CAP_SYS_PERFMON privileged process Date: Sat, 18 Jan 2020 21:48:24 +0300 [thread overview] Message-ID: <63e070c1-413c-efef-ccd6-97e70d8a90d0@linux.intel.com> (raw) In-Reply-To: <20200117105153.GB6144@willie-the-truck> On 17.01.2020 13:51, Will Deacon wrote: > On Wed, Dec 18, 2019 at 12:30:29PM +0300, Alexey Budankov wrote: >> >> Open access to monitoring for CAP_SYS_PERFMON privileged processes. >> For backward compatibility reasons access to the monitoring remains open >> for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage for secure >> monitoring is discouraged with respect to CAP_SYS_PERFMON capability. >> >> Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com> >> --- >> drivers/perf/arm_spe_pmu.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/perf/arm_spe_pmu.c b/drivers/perf/arm_spe_pmu.c >> index 4e4984a55cd1..5dff81bc3324 100644 >> --- a/drivers/perf/arm_spe_pmu.c >> +++ b/drivers/perf/arm_spe_pmu.c >> @@ -274,7 +274,7 @@ static u64 arm_spe_event_to_pmscr(struct perf_event *event) >> if (!attr->exclude_kernel) >> reg |= BIT(SYS_PMSCR_EL1_E1SPE_SHIFT); >> >> - if (IS_ENABLED(CONFIG_PID_IN_CONTEXTIDR) && capable(CAP_SYS_ADMIN)) >> + if (IS_ENABLED(CONFIG_PID_IN_CONTEXTIDR) && perfmon_capable()) >> reg |= BIT(SYS_PMSCR_EL1_CX_SHIFT); >> >> return reg; >> @@ -700,7 +700,7 @@ static int arm_spe_pmu_event_init(struct perf_event *event) >> return -EOPNOTSUPP; >> >> reg = arm_spe_event_to_pmscr(event); >> - if (!capable(CAP_SYS_ADMIN) && >> + if (!perfmon_capable() && >> (reg & (BIT(SYS_PMSCR_EL1_PA_SHIFT) | >> BIT(SYS_PMSCR_EL1_CX_SHIFT) | >> BIT(SYS_PMSCR_EL1_PCT_SHIFT)))) > > Acked-by: Will Deacon <will@kernel.org> > > Worth noting that this allows profiling of *physical* addresses used by > memory access instructions and so probably has some security implications > beyond the usual "but perf is buggy" line of reasoning. Good to know. Thank you! The data on physical addresses used by memory access instructions can already be provided under CAP_SYS_ADMIN privileges [1] thus, I suppose, any implications you have mentioned are already in place. I believe providing the data under CAP_PERFMON alone without the rest of CAP_SYS_ADMIN credentials decreases chances to misuse the data for harm and makes the monitoring more secure. ~Alexey [1] https://www.kernel.org/doc/html/latest/admin-guide/perf-security.html > > Will >
WARNING: multiple messages have this Message-ID (diff)
From: Alexey Budankov <alexey.budankov@linux.intel.com> To: Will Deacon <will@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com>, Song Liu <songliubraving@fb.com>, Peter Zijlstra <peterz@infradead.org>, Benjamin Herrenschmidt <benh@kernel.crashing.org>, "joonas.lahtinen@linux.intel.com" <joonas.lahtinen@linux.intel.com>, 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>, Alexander Shishkin <alexander.shishkin@linux.intel.com>, Ingo Molnar <mingo@redhat.com>, Serge Hallyn <serge@hallyn.com>, Robert Richter <rric@kernel.org>, Kees Cook <keescook@chromium.org>, Jann Horn <jannh@google.com>, "jani.nikula@linux.intel.com" <jani.nikula@linux.intel.com>, Arnaldo Carvalho de Melo <acme@kernel.org>, "rodrigo.vivi@intel.com" <rodrigo.vivi@intel.com>, Namhyung Kim <namhyung@kernel.org>, Thomas Gleixner <tglx@linutronix.de>, linux-arm-kernel@lists.infradead.org, linux-kernel <linux-kernel@vger.kernel.org>, Casey Schaufler <casey@schaufler-ca.com> Subject: Re: [PATCH v4 8/9] drivers/perf: open access for CAP_SYS_PERFMON privileged process Date: Sat, 18 Jan 2020 21:48:24 +0300 [thread overview] Message-ID: <63e070c1-413c-efef-ccd6-97e70d8a90d0@linux.intel.com> (raw) In-Reply-To: <20200117105153.GB6144@willie-the-truck> On 17.01.2020 13:51, Will Deacon wrote: > On Wed, Dec 18, 2019 at 12:30:29PM +0300, Alexey Budankov wrote: >> >> Open access to monitoring for CAP_SYS_PERFMON privileged processes. >> For backward compatibility reasons access to the monitoring remains open >> for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage for secure >> monitoring is discouraged with respect to CAP_SYS_PERFMON capability. >> >> Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com> >> --- >> drivers/perf/arm_spe_pmu.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/perf/arm_spe_pmu.c b/drivers/perf/arm_spe_pmu.c >> index 4e4984a55cd1..5dff81bc3324 100644 >> --- a/drivers/perf/arm_spe_pmu.c >> +++ b/drivers/perf/arm_spe_pmu.c >> @@ -274,7 +274,7 @@ static u64 arm_spe_event_to_pmscr(struct perf_event *event) >> if (!attr->exclude_kernel) >> reg |= BIT(SYS_PMSCR_EL1_E1SPE_SHIFT); >> >> - if (IS_ENABLED(CONFIG_PID_IN_CONTEXTIDR) && capable(CAP_SYS_ADMIN)) >> + if (IS_ENABLED(CONFIG_PID_IN_CONTEXTIDR) && perfmon_capable()) >> reg |= BIT(SYS_PMSCR_EL1_CX_SHIFT); >> >> return reg; >> @@ -700,7 +700,7 @@ static int arm_spe_pmu_event_init(struct perf_event *event) >> return -EOPNOTSUPP; >> >> reg = arm_spe_event_to_pmscr(event); >> - if (!capable(CAP_SYS_ADMIN) && >> + if (!perfmon_capable() && >> (reg & (BIT(SYS_PMSCR_EL1_PA_SHIFT) | >> BIT(SYS_PMSCR_EL1_CX_SHIFT) | >> BIT(SYS_PMSCR_EL1_PCT_SHIFT)))) > > Acked-by: Will Deacon <will@kernel.org> > > Worth noting that this allows profiling of *physical* addresses used by > memory access instructions and so probably has some security implications > beyond the usual "but perf is buggy" line of reasoning. Good to know. Thank you! The data on physical addresses used by memory access instructions can already be provided under CAP_SYS_ADMIN privileges [1] thus, I suppose, any implications you have mentioned are already in place. I believe providing the data under CAP_PERFMON alone without the rest of CAP_SYS_ADMIN credentials decreases chances to misuse the data for harm and makes the monitoring more secure. ~Alexey [1] https://www.kernel.org/doc/html/latest/admin-guide/perf-security.html > > Will > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-01-18 18:48 UTC|newest] Thread overview: 148+ 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:16 ` [Intel-gfx] " Alexey Budankov 2019-12-18 9:16 ` Alexey Budankov 2019-12-18 9:16 ` Alexey Budankov 2019-12-18 9:16 ` 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 9:24 ` [Intel-gfx] " Alexey Budankov 2019-12-18 9:24 ` Alexey Budankov 2019-12-18 9:24 ` Alexey Budankov 2019-12-18 9:24 ` Alexey Budankov 2019-12-18 19:56 ` Stephen Smalley 2019-12-18 19:56 ` [Intel-gfx] " Stephen Smalley 2019-12-18 19:56 ` Stephen Smalley 2019-12-18 19:56 ` Stephen Smalley 2019-12-18 19:56 ` Stephen Smalley 2019-12-28 3:53 ` Serge E. Hallyn 2019-12-28 3:53 ` [Intel-gfx] " Serge E. Hallyn 2019-12-28 3:53 ` Serge E. Hallyn 2019-12-28 3:53 ` Serge E. Hallyn 2020-01-13 20:25 ` Song Liu 2020-01-13 20:25 ` [Intel-gfx] " Song Liu 2020-01-13 20:25 ` Song Liu 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 2019-12-18 9:25 ` [Intel-gfx] " Alexey Budankov 2019-12-18 9:25 ` Alexey Budankov 2019-12-18 9:25 ` Alexey Budankov 2019-12-18 9:25 ` Alexey Budankov 2020-01-08 16:07 ` Peter Zijlstra 2020-01-08 16:07 ` [Intel-gfx] " Peter Zijlstra 2020-01-08 16:07 ` Peter Zijlstra 2020-01-08 16:07 ` Peter Zijlstra 2020-01-08 16:07 ` Peter Zijlstra 2020-01-09 11:36 ` Alexey Budankov 2020-01-09 11:36 ` [Intel-gfx] " Alexey Budankov 2020-01-09 11:36 ` Alexey Budankov 2020-01-09 11:36 ` Alexey Budankov 2020-01-09 11:36 ` Alexey Budankov 2020-01-10 14:02 ` Peter Zijlstra 2020-01-10 14:02 ` [Intel-gfx] " Peter Zijlstra 2020-01-10 14:02 ` Peter Zijlstra 2020-01-10 14:02 ` Peter Zijlstra 2020-01-10 15:52 ` Masami Hiramatsu 2020-01-10 15:52 ` [Intel-gfx] " Masami Hiramatsu 2020-01-10 15:52 ` Masami Hiramatsu 2020-01-10 15:52 ` Masami Hiramatsu 2020-01-10 16:45 ` Arnaldo Carvalho de Melo 2020-01-10 16:45 ` [Intel-gfx] " Arnaldo Carvalho de Melo 2020-01-10 16:45 ` Arnaldo Carvalho de Melo 2020-01-10 16:45 ` Arnaldo Carvalho de Melo 2020-01-10 23:47 ` Masami Hiramatsu 2020-01-10 23:47 ` [Intel-gfx] " Masami Hiramatsu 2020-01-10 23:47 ` Masami Hiramatsu 2020-01-10 23:47 ` Masami Hiramatsu 2020-01-11 0:23 ` Song Liu 2020-01-11 0:23 ` [Intel-gfx] " Song Liu 2020-01-11 0:23 ` Song Liu 2020-01-11 0:23 ` Song Liu 2020-01-11 0:35 ` arnaldo.melo 2020-01-11 0:35 ` [Intel-gfx] " arnaldo.melo 2020-01-11 9:57 ` Alexey Budankov 2020-01-13 20:39 ` Song Liu 2020-01-14 3:25 ` Masami Hiramatsu 2020-01-14 5:17 ` Alexei Starovoitov 2020-01-14 9:47 ` Alexey Budankov 2020-01-14 18:06 ` Alexei Starovoitov 2020-01-14 18:50 ` Alexey Budankov 2020-01-15 1:52 ` Alexei Starovoitov 2020-01-15 5:15 ` Alexey Budankov 2020-04-01 20:50 ` Alexey Budankov 2020-04-03 13:55 ` Alexey Budankov 2020-04-03 13:56 ` Alexey Budankov 2020-01-15 9:45 ` Masami Hiramatsu 2020-01-15 12:11 ` Alexey Budankov 2020-01-14 12:04 ` Masami Hiramatsu 2020-01-12 1:44 ` Masami Hiramatsu 2020-01-12 1:44 ` [Intel-gfx] " Masami Hiramatsu 2020-01-12 1:44 ` Masami Hiramatsu 2020-01-10 16:41 ` Alexey Budankov 2020-01-10 16:41 ` [Intel-gfx] " Alexey Budankov 2020-01-10 16:41 ` Alexey Budankov 2020-01-10 16:41 ` Alexey Budankov 2020-01-10 17:34 ` Alexey Budankov 2020-01-10 17:34 ` [Intel-gfx] " Alexey Budankov 2020-01-10 17:34 ` Alexey Budankov 2020-01-10 17:34 ` Alexey Budankov 2020-04-01 20:49 ` Alexey Budankov 2020-04-03 14:28 ` 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:26 ` [Intel-gfx] " Alexey Budankov 2019-12-18 9:26 ` Alexey Budankov 2019-12-18 9:26 ` Alexey Budankov 2019-12-18 9:26 ` 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-18 9:27 ` [Intel-gfx] " Alexey Budankov 2019-12-18 9:27 ` Alexey Budankov 2019-12-18 9:27 ` Alexey Budankov 2019-12-18 9:27 ` Alexey Budankov 2019-12-19 9:10 ` Lionel Landwerlin 2019-12-19 9:10 ` [Intel-gfx] " Lionel Landwerlin 2019-12-19 9:10 ` Lionel Landwerlin 2019-12-19 9:10 ` Lionel Landwerlin 2019-12-19 9:10 ` Lionel Landwerlin 2019-12-18 9:28 ` [PATCH v4 5/9] trace/bpf_trace: " Alexey Budankov 2019-12-18 9:28 ` [Intel-gfx] " Alexey Budankov 2019-12-18 9:28 ` Alexey Budankov 2019-12-18 9:28 ` Alexey Budankov 2019-12-18 9:28 ` Alexey Budankov 2020-01-13 20:47 ` Song Liu 2020-01-13 20:47 ` [Intel-gfx] " Song Liu 2020-01-13 20:47 ` Song Liu 2020-01-13 20:47 ` Song Liu 2019-12-18 9:28 ` [PATCH v4 6/9] powerpc/perf: " Alexey Budankov 2019-12-18 9:28 ` [Intel-gfx] " Alexey Budankov 2019-12-18 9:28 ` Alexey Budankov 2019-12-18 9:28 ` Alexey Budankov 2019-12-18 9:28 ` Alexey Budankov 2019-12-18 9:29 ` [PATCH v4 7/9] parisc/perf: " Alexey Budankov 2019-12-18 9:29 ` [Intel-gfx] " Alexey Budankov 2019-12-18 9:29 ` Alexey Budankov 2019-12-18 9:29 ` Alexey Budankov 2019-12-18 9:29 ` Alexey Budankov 2020-01-27 8:52 ` Helge Deller 2020-01-27 8:52 ` [Intel-gfx] " Helge Deller 2020-01-27 8:52 ` Helge Deller 2020-01-27 8:52 ` Helge Deller 2020-01-27 8:52 ` Helge Deller 2019-12-18 9:30 ` [PATCH v4 8/9] drivers/perf: " Alexey Budankov 2019-12-18 9:30 ` [Intel-gfx] " Alexey Budankov 2019-12-18 9:30 ` Alexey Budankov 2019-12-18 9:30 ` Alexey Budankov 2019-12-18 9:30 ` Alexey Budankov 2020-01-17 10:51 ` Will Deacon 2020-01-17 10:51 ` [Intel-gfx] " Will Deacon 2020-01-17 10:51 ` Will Deacon 2020-01-17 10:51 ` Will Deacon 2020-01-17 21:33 ` Alexey Budankov 2020-01-17 21:33 ` [Intel-gfx] " Alexey Budankov 2020-01-17 21:33 ` Alexey Budankov 2020-01-17 21:33 ` Alexey Budankov 2020-01-18 18:48 ` Alexey Budankov [this message] 2020-01-18 18:48 ` Alexey Budankov 2019-12-18 9:31 ` [PATCH v4 9/9] drivers/oprofile: " Alexey Budankov 2019-12-18 9:31 ` [Intel-gfx] " Alexey Budankov 2019-12-18 9:31 ` Alexey Budankov 2019-12-18 9:31 ` Alexey Budankov 2019-12-18 9:31 ` Alexey Budankov 2019-12-18 10:11 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for Introduce CAP_SYS_PERFMON to secure system performance monitoring and observability (rev3) Patchwork
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=63e070c1-413c-efef-ccd6-97e70d8a90d0@linux.intel.com \ --to=alexey.budankov@linux.intel.com \ --cc=acme@kernel.org \ --cc=ak@linux.intel.com \ --cc=alexander.shishkin@linux.intel.com \ --cc=ast@kernel.org \ --cc=benh@kernel.crashing.org \ --cc=casey@schaufler-ca.com \ --cc=eranian@google.com \ --cc=ilubashe@akamai.com \ --cc=james.bottomley@hansenpartnership.com \ --cc=jani.nikula@linux.intel.com \ --cc=jannh@google.com \ --cc=jmorris@namei.org \ --cc=jolsa@redhat.com \ --cc=joonas.lahtinen@linux.intel.com \ --cc=keescook@chromium.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=mingo@redhat.com \ --cc=mpe@ellerman.id.au \ --cc=namhyung@kernel.org \ --cc=paulus@samba.org \ --cc=peterz@infradead.org \ --cc=rodrigo.vivi@intel.com \ --cc=rric@kernel.org \ --cc=serge@hallyn.com \ --cc=songliubraving@fb.com \ --cc=tglx@linutronix.de \ --cc=will.deacon@arm.com \ --cc=will@kernel.org \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.