All of lore.kernel.org
 help / color / mirror / Atom feed
From: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: Madhavan Srinivasan <maddy@linux.ibm.com>,
	Peter Zijlstra <peterz@infradead.org>,
	omosnace@redhat.com, acme@kernel.org,
	Jiri Olsa <jolsa@kernel.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	kan.liang@linux.intel.com
Subject: Re: [PATCH] powerpc/perf: Fix handling of privilege level checks in perf interrupt context
Date: Wed, 24 Feb 2021 16:40:17 +0530	[thread overview]
Message-ID: <58E4DBFF-0B7C-4853-AD8D-8C937C34F78C@linux.vnet.ibm.com> (raw)
In-Reply-To: <87czwrt057.fsf@mpe.ellerman.id.au>



> On 23-Feb-2021, at 6:24 PM, Michael Ellerman <mpe@ellerman.id.au> wrote:
> 
> Peter Zijlstra <peterz@infradead.org> writes:
>> On Tue, Feb 23, 2021 at 01:31:49AM -0500, Athira Rajeev wrote:
>>> Running "perf mem record" in powerpc platforms with selinux enabled
>>> resulted in soft lockup's. Below call-trace was seen in the logs:
> ...
>>> 
>>> Since the purpose of this security hook is to control access to
>>> perf_event_open, it is not right to call this in interrupt context.
>>> But in case of powerpc PMU, we need the privilege checks for specific
>>> samples from branch history ring buffer and sampling register values.
>> 
>> I'm confused... why would you need those checks at event time? Either
>> the event has perf_event_attr::exclude_kernel and it then isn't allowed
>> to expose kernel addresses, or it doesn't and it is.
> 
> Well one of us is confused that's for sure ^_^
> 
> I missed/forgot that we had that logic in open.
> 
> I think the reason we got here is that in the past we didn't have the
> event in the low-level routines where we want to check,
> power_pmu_bhrb_read() and perf_get_data_addr(), so we hacked in a
> perf_paranoid_kernel() check. Which was wrong.
> 
> Then Joel's patch plumbed the event through and switched those paranoid
> checks to perf_allow_kernel().
> 
> Anyway, we'll just switch those to exclude_kernel checks.
> 
>> There should never be an event-time question of permission like this. If
>> you allow creation of an event, you're allowing the data it generates.
> 
> Ack.

Thanks for all the reviews. I will send a V2 with using 'event->attr.exclude_kernel' in the checks.

Athira 
> 
> cheers

      reply	other threads:[~2021-02-24 11:11 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-23  6:31 [PATCH] powerpc/perf: Fix handling of privilege level checks in perf interrupt context Athira Rajeev
2021-02-23 10:36 ` Ondrej Mosnacek
2021-02-23 10:36   ` Ondrej Mosnacek
2021-02-23 11:03 ` Peter Zijlstra
2021-02-23 12:54   ` Michael Ellerman
2021-02-24 11:10     ` Athira Rajeev [this message]

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=58E4DBFF-0B7C-4853-AD8D-8C937C34F78C@linux.vnet.ibm.com \
    --to=atrajeev@linux.vnet.ibm.com \
    --cc=acme@kernel.org \
    --cc=jolsa@kernel.org \
    --cc=kan.liang@linux.intel.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=maddy@linux.ibm.com \
    --cc=mpe@ellerman.id.au \
    --cc=omosnace@redhat.com \
    --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.