From: Michael Neuling <mikey@neuling.org> To: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com>, Ingo Molnar <mingo@kernel.org>, LKML <linux-kernel@vger.kernel.org>, "ak@linux.intel.com" <ak@linux.intel.com>, michael@ellerman.id.au, benh@kernel.crashing.org, Linux PPC dev <linuxppc-dev@ozlabs.org> Subject: Re: [PATCH 3/3] perf, x86, lbr: Demand proper privileges for PERF_SAMPLE_BRANCH_KERNEL Date: Thu, 16 May 2013 20:15:17 +1000 [thread overview] Message-ID: <8578.1368699317@ale.ozlabs.ibm.com> (raw) In-Reply-To: <20130516090916.GF19669@dyad.programming.kicks-ass.net> Peter Zijlstra <peterz@infradead.org> wrote: > On Wed, May 15, 2013 at 03:37:22PM +0200, Stephane Eranian wrote: > > On Fri, May 3, 2013 at 2:11 PM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote: > > > We should always have proper privileges when requesting kernel data. > > > > > > Cc: Andi Kleen <ak@linux.intel.com> > > > Cc: eranian@google.com > > > Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> > > > Link: http://lkml.kernel.org/n/tip-v0x9ky3ahzr6nm3c6ilwrili@git.kernel.org > > > --- > > > arch/x86/kernel/cpu/perf_event_intel_lbr.c | 5 ++++- > > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > > > --- a/arch/x86/kernel/cpu/perf_event_intel_lbr.c > > > +++ b/arch/x86/kernel/cpu/perf_event_intel_lbr.c > > > @@ -318,8 +318,11 @@ static void intel_pmu_setup_sw_lbr_filte > > > if (br_type & PERF_SAMPLE_BRANCH_USER) > > > mask |= X86_BR_USER; > > > > > > - if (br_type & PERF_SAMPLE_BRANCH_KERNEL) > > > + if (br_type & PERF_SAMPLE_BRANCH_KERNEL) { > > > + if (perf_paranoid_kernel() && !capable(CAP_SYS_ADMIN)) > > > + return -EACCES; > > > mask |= X86_BR_KERNEL; > > > + } > > > > > This will prevent regular users from capturing kernel -> kernel branches. > > But it won't prevent users from getting kernel -> user branches. Thus > > some kernel address will still be captured. I guess they could be eliminated > > by the sw_filter. > > > > When using LBR priv level filtering, the filter applies to the branch target > > only. > > How about something like the below? It also adds the branch flags > Mikey wanted for PowerPC. Peter, BTW PowerPC also has the ability to filter on conditional branches. Any chance we could add something like the follow to perf also? Mikey diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h index fb104e5..891c769 100644 --- a/include/uapi/linux/perf_event.h +++ b/include/uapi/linux/perf_event.h @@ -157,8 +157,9 @@ enum perf_branch_sample_type { PERF_SAMPLE_BRANCH_ANY_CALL = 1U << 4, /* any call branch */ PERF_SAMPLE_BRANCH_ANY_RETURN = 1U << 5, /* any return branch */ PERF_SAMPLE_BRANCH_IND_CALL = 1U << 6, /* indirect calls */ + PERF_SAMPLE_BRANCH_CONDITIONAL = 1U << 7, /* conditional branches */ - PERF_SAMPLE_BRANCH_MAX = 1U << 7, /* non-ABI */ + PERF_SAMPLE_BRANCH_MAX = 1U << 8, /* non-ABI */ }; #define PERF_SAMPLE_BRANCH_PLM_ALL \ diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c index cdf58ec..5b0b89d 100644 --- a/tools/perf/builtin-record.c +++ b/tools/perf/builtin-record.c @@ -676,6 +676,7 @@ static const struct branch_mode branch_modes[] = { BRANCH_OPT("any_call", PERF_SAMPLE_BRANCH_ANY_CALL), BRANCH_OPT("any_ret", PERF_SAMPLE_BRANCH_ANY_RETURN), BRANCH_OPT("ind_call", PERF_SAMPLE_BRANCH_IND_CALL), + BRANCH_OPT("cnd", PERF_SAMPLE_BRANCH_CONDITIONAL), BRANCH_END };
WARNING: multiple messages have this Message-ID (diff)
From: Michael Neuling <mikey@neuling.org> To: Peter Zijlstra <peterz@infradead.org> Cc: "ak@linux.intel.com" <ak@linux.intel.com>, LKML <linux-kernel@vger.kernel.org>, Stephane Eranian <eranian@google.com>, Linux PPC dev <linuxppc-dev@ozlabs.org>, Ingo Molnar <mingo@kernel.org> Subject: Re: [PATCH 3/3] perf, x86, lbr: Demand proper privileges for PERF_SAMPLE_BRANCH_KERNEL Date: Thu, 16 May 2013 20:15:17 +1000 [thread overview] Message-ID: <8578.1368699317@ale.ozlabs.ibm.com> (raw) In-Reply-To: <20130516090916.GF19669@dyad.programming.kicks-ass.net> Peter Zijlstra <peterz@infradead.org> wrote: > On Wed, May 15, 2013 at 03:37:22PM +0200, Stephane Eranian wrote: > > On Fri, May 3, 2013 at 2:11 PM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote: > > > We should always have proper privileges when requesting kernel data. > > > > > > Cc: Andi Kleen <ak@linux.intel.com> > > > Cc: eranian@google.com > > > Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> > > > Link: http://lkml.kernel.org/n/tip-v0x9ky3ahzr6nm3c6ilwrili@git.kernel.org > > > --- > > > arch/x86/kernel/cpu/perf_event_intel_lbr.c | 5 ++++- > > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > > > --- a/arch/x86/kernel/cpu/perf_event_intel_lbr.c > > > +++ b/arch/x86/kernel/cpu/perf_event_intel_lbr.c > > > @@ -318,8 +318,11 @@ static void intel_pmu_setup_sw_lbr_filte > > > if (br_type & PERF_SAMPLE_BRANCH_USER) > > > mask |= X86_BR_USER; > > > > > > - if (br_type & PERF_SAMPLE_BRANCH_KERNEL) > > > + if (br_type & PERF_SAMPLE_BRANCH_KERNEL) { > > > + if (perf_paranoid_kernel() && !capable(CAP_SYS_ADMIN)) > > > + return -EACCES; > > > mask |= X86_BR_KERNEL; > > > + } > > > > > This will prevent regular users from capturing kernel -> kernel branches. > > But it won't prevent users from getting kernel -> user branches. Thus > > some kernel address will still be captured. I guess they could be eliminated > > by the sw_filter. > > > > When using LBR priv level filtering, the filter applies to the branch target > > only. > > How about something like the below? It also adds the branch flags > Mikey wanted for PowerPC. Peter, BTW PowerPC also has the ability to filter on conditional branches. Any chance we could add something like the follow to perf also? Mikey diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h index fb104e5..891c769 100644 --- a/include/uapi/linux/perf_event.h +++ b/include/uapi/linux/perf_event.h @@ -157,8 +157,9 @@ enum perf_branch_sample_type { PERF_SAMPLE_BRANCH_ANY_CALL = 1U << 4, /* any call branch */ PERF_SAMPLE_BRANCH_ANY_RETURN = 1U << 5, /* any return branch */ PERF_SAMPLE_BRANCH_IND_CALL = 1U << 6, /* indirect calls */ + PERF_SAMPLE_BRANCH_CONDITIONAL = 1U << 7, /* conditional branches */ - PERF_SAMPLE_BRANCH_MAX = 1U << 7, /* non-ABI */ + PERF_SAMPLE_BRANCH_MAX = 1U << 8, /* non-ABI */ }; #define PERF_SAMPLE_BRANCH_PLM_ALL \ diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c index cdf58ec..5b0b89d 100644 --- a/tools/perf/builtin-record.c +++ b/tools/perf/builtin-record.c @@ -676,6 +676,7 @@ static const struct branch_mode branch_modes[] = { BRANCH_OPT("any_call", PERF_SAMPLE_BRANCH_ANY_CALL), BRANCH_OPT("any_ret", PERF_SAMPLE_BRANCH_ANY_RETURN), BRANCH_OPT("ind_call", PERF_SAMPLE_BRANCH_IND_CALL), + BRANCH_OPT("cnd", PERF_SAMPLE_BRANCH_CONDITIONAL), BRANCH_END };
next prev parent reply other threads:[~2013-05-16 10:15 UTC|newest] Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-05-03 12:11 [PATCH 0/3] Various perf patches Peter Zijlstra 2013-05-03 12:11 ` [PATCH 1/3] perf, x86: Blacklist all MEM_*_RETIRED events for IVB Peter Zijlstra 2013-05-03 14:35 ` Andi Kleen 2013-05-03 17:00 ` Peter Zijlstra 2013-05-15 14:20 ` Stephane Eranian 2013-05-15 16:51 ` Peter Zijlstra 2013-05-16 15:42 ` Stephane Eranian 2013-05-16 16:07 ` Andi Kleen 2013-05-16 16:26 ` Stephane Eranian 2013-05-04 8:20 ` [tip:perf/urgent] perf/x86: Blacklist all MEM_*_RETIRED events for Ivy Bridge tip-bot for Peter Zijlstra 2013-05-03 12:11 ` [PATCH 2/3] perf, x86, lbr: Fix LBR filter Peter Zijlstra 2013-05-03 14:34 ` Andi Kleen 2013-05-04 6:34 ` Ingo Molnar 2013-05-04 8:21 ` [tip:perf/urgent] perf/x86/intel/lbr: " tip-bot for Peter Zijlstra 2013-05-03 12:11 ` [PATCH 3/3] perf, x86, lbr: Demand proper privileges for PERF_SAMPLE_BRANCH_KERNEL Peter Zijlstra 2013-05-03 14:41 ` Andi Kleen 2013-05-04 8:22 ` [tip:perf/urgent] perf/x86/intel/lbr: " tip-bot for Peter Zijlstra 2013-05-04 11:19 ` Borislav Petkov 2013-05-05 9:05 ` Ingo Molnar 2013-05-06 8:07 ` Peter Zijlstra 2013-05-06 9:42 ` Ingo Molnar 2013-05-15 13:37 ` [PATCH 3/3] perf, x86, lbr: " Stephane Eranian 2013-05-15 14:30 ` Peter Zijlstra 2013-05-16 9:09 ` Peter Zijlstra 2013-05-16 9:17 ` Peter Zijlstra 2013-05-16 10:09 ` Michael Neuling 2013-05-16 10:09 ` Michael Neuling 2013-05-16 10:15 ` Michael Neuling [this message] 2013-05-16 10:15 ` Michael Neuling 2013-05-16 11:16 ` Peter Zijlstra 2013-05-16 11:16 ` Peter Zijlstra 2013-05-16 15:36 ` Stephane Eranian 2013-05-16 15:36 ` Stephane Eranian 2013-05-17 11:12 ` Peter Zijlstra 2013-05-17 11:12 ` Peter Zijlstra 2013-05-17 11:32 ` Michael Neuling 2013-05-17 11:32 ` Michael Neuling 2013-05-17 11:39 ` Peter Zijlstra 2013-05-17 11:39 ` Peter Zijlstra 2013-05-17 21:39 ` Stephane Eranian 2013-05-17 21:39 ` Stephane Eranian 2013-05-17 22:14 ` Michael Neuling 2013-05-17 22:14 ` Michael Neuling 2013-05-17 22:59 ` Stephane Eranian 2013-05-17 22:59 ` Stephane Eranian 2013-05-21 5:41 ` Michael Neuling 2013-05-21 5:41 ` Michael Neuling 2013-05-21 8:50 ` Peter Zijlstra 2013-05-21 8:50 ` Peter Zijlstra 2013-05-21 13:46 ` Stephane Eranian 2013-05-21 13:46 ` Stephane Eranian 2013-05-21 13:55 ` Stephane Eranian 2013-05-21 13:55 ` Stephane Eranian 2013-05-22 6:43 ` Anshuman Khandual 2013-05-22 12:23 ` Stephane Eranian 2013-05-22 14:51 ` Anshuman Khandual
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=8578.1368699317@ale.ozlabs.ibm.com \ --to=mikey@neuling.org \ --cc=ak@linux.intel.com \ --cc=benh@kernel.crashing.org \ --cc=eranian@google.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linuxppc-dev@ozlabs.org \ --cc=michael@ellerman.id.au \ --cc=mingo@kernel.org \ --cc=peterz@infradead.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.