All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anshuman Khandual <khandual@linux.vnet.ibm.com>
To: Stephane Eranian <eranian@google.com>
Cc: Michael Neuling <mikey@neuling.org>,
	"ak@linux.intel.com" <ak@linux.intel.com>,
	Peter Zijlstra <peterz@infradead.org>,
	LKML <linux-kernel@vger.kernel.org>,
	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: Wed, 22 May 2013 12:13:08 +0530	[thread overview]
Message-ID: <519C68FC.2060304@linux.vnet.ibm.com> (raw)
In-Reply-To: <CABPqkBRpbh4BO7cMBysE+E+n5E_o_KesEhEZ3Wq49B3MeW786A@mail.gmail.com>

On 05/21/2013 07:25 PM, Stephane Eranian wrote:
> On Thu, May 16, 2013 at 12:15 PM, Michael Neuling <mikey@neuling.org> wrote:
>> 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 */
>>
> I would use PERF_SAMPLE_BRANCH_COND here.
> 
>> -       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),
> 
> use "cond"
> 
>>         BRANCH_END
>>  };
>>
> 
> And if you do this, you also need to update the x86
> perf_event_intel_lbr.c mapping
> tables to fill out the entries for PERF_SAMPLE_BRANCH_COND:
> 
>         [PERF_SAMPLE_BRANCH_COND]       = LBR_JCC,
> 
> And you also need to update intel_pmu_setup_sw_lbr_filter()
> to handle the conversion to x86 instructions:
> 
>        if (br_type & PERF_SAMPLE_BRANCH_COND)
>                 mask |= X86_BR_JCC;
> 
> 
> You also need to update the perf-record.txt documentation to list cond
> as a possible
> branch filter.

Hey Stephane,

I have incorporated all the review comments into the patch series
https://lkml.org/lkml/2013/5/22/51.

Regards
Anshuman


  reply	other threads:[~2013-05-22  6:44 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
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 [this message]
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=519C68FC.2060304@linux.vnet.ibm.com \
    --to=khandual@linux.vnet.ibm.com \
    --cc=ak@linux.intel.com \
    --cc=eranian@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=mikey@neuling.org \
    --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: link
Be 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.