All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Will Deacon <will@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Jiri Olsa <jolsa@redhat.com>, Ian Rogers <irogers@google.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>,
	Zachary.Leaf@arm.com, Raphael Gault <raphael.gault@arm.com>,
	Jonathan Cameron <Jonathan.Cameron@huawei.com>,
	Namhyung Kim <namhyung@kernel.org>,
	Itaru Kitayama <itaru.kitayama@gmail.com>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v6 02/10] arm64: perf: Enable PMU counter direct access for perf event
Date: Mon, 19 Apr 2021 14:00:17 -0500	[thread overview]
Message-ID: <CAL_JsqKV_m8tzKpBq=3w-LUksWLmU-1mO1GgQS1nB9sDJanEpQ@mail.gmail.com> (raw)
In-Reply-To: <20210419161429.GA30998@willie-the-truck>

On Mon, Apr 19, 2021 at 11:14 AM Will Deacon <will@kernel.org> wrote:
>
> On Thu, Apr 08, 2021 at 01:38:17PM -0500, Rob Herring wrote:
> > On Thu, Apr 8, 2021 at 6:08 AM Mark Rutland <mark.rutland@arm.com> wrote:
> > > On Wed, Apr 07, 2021 at 01:44:37PM +0100, Will Deacon wrote:
> > > > On Thu, Apr 01, 2021 at 02:45:21PM -0500, Rob Herring wrote:
> > > > > On Wed, Mar 31, 2021 at 11:01 AM Will Deacon <will@kernel.org> wrote:
> > > > I guess I'm just worried about exposing the counters to userspace after
> > > > the PMU driver (or perf core?) thinks that they're no longer exposed in
> > > > case we leak other events.
> > >
> > > IMO that's not practically different from the single-PMU case (i.e.
> > > multi-PMU isn't material, either we have a concern with leaking or we
> > > don't); more on that below.
>
> Well, maybe. It looks the single-PMU case is exposed to the same issue,
> but I think a solution needs to take into account the multi-PMU situation.
>
> > > While it looks odd to place this on the mm, I don't think it's the end
> > > of the world.
> > >
> > > > However, I'm not sure how this is supposed to work normally: what
> > > > happens if e.g. a privileged user has a per-cpu counter for a kernel
> > > > event while a task has a counter with direct access -- can that task
> > > > read the kernel event out of the PMU registers from userspace?
> > >
> > > Yes -- userspace could go read any counters even though it isn't
> > > supposed to, and could potentially infer information from those. It
> > > won't have access to the config registers or kernel data structures, so
> > > it isn't guaranteed to know what the even is or when it is
> > > context-switched/reprogrammed/etc.
> > >
> > > If we believe that's a problem, then it's difficult to do anything
> > > robust other than denying userspace access entirely, since disabling
> > > userspace access while in use would surprise applications, and denying
> > > privileged events would need some global state that we consult at event
> > > creation time (in addition to being an inversion of privilege).
> > >
> > > IIRC there was some fuss about this a while back on x86; I'll go dig and
> > > see what I can find, unless Peter has a memory...
> >
> > Maybe this one[1].
> >
> > Rob
> >
> > [1] https://lore.kernel.org/lkml/20200730123815.18518-1-kan.liang@linux.intel.com/
>
> Going through the archives and talking to Peter, it looks like this is still
> an active area of concern:
>
>   - There are patches to clear "dirty" counters on context-switch. They were
>     queued for 5.13 but broke -tip on Friday:
>
>     https://lore.kernel.org/lkml/YHm%2FM4za2LpRYePw@hirez.programming.kicks-ass.net/

Yes, nice timing. I've reworked the arm64 support to do the same
things (minus the breakage). And it looks like we can simplify things
a bit by moving all the context switch handling into .sched_task() and
out of switch_mm. Unless there's some case where that wouldn't work
that I'm not aware of (entirely likely).

>   - Per-cpu events cannot be protected in software:
>
>     https://lore.kernel.org/lkml/CALCETrVVPzUd_hQ8xoomHn_wWRQJUvROeCt2do4_D4ROZoAVMg@mail.gmail.com/
>
>     so without hardware support, we need a way to disable user access for
>     people that care about this leakage
>
> x86 has an "rdpmc" file exposed for the PMU device in sysfs which allows
> access to be disabled. I don't think these patches add such a thing, and
> that's where the fun with multi-PMU machines would come into play.

The fun is because sysfs will end up with multiple 'rdpmc' files or
something else?

Rob

WARNING: multiple messages have this Message-ID
From: Rob Herring <robh@kernel.org>
To: Will Deacon <will@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	 Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	 Arnaldo Carvalho de Melo <acme@kernel.org>,
	Jiri Olsa <jolsa@redhat.com>, Ian Rogers <irogers@google.com>,
	 Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	 Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>,
	Zachary.Leaf@arm.com,  Raphael Gault <raphael.gault@arm.com>,
	Jonathan Cameron <Jonathan.Cameron@huawei.com>,
	 Namhyung Kim <namhyung@kernel.org>,
	Itaru Kitayama <itaru.kitayama@gmail.com>,
	 linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v6 02/10] arm64: perf: Enable PMU counter direct access for perf event
Date: Mon, 19 Apr 2021 14:00:17 -0500	[thread overview]
Message-ID: <CAL_JsqKV_m8tzKpBq=3w-LUksWLmU-1mO1GgQS1nB9sDJanEpQ@mail.gmail.com> (raw)
In-Reply-To: <20210419161429.GA30998@willie-the-truck>

On Mon, Apr 19, 2021 at 11:14 AM Will Deacon <will@kernel.org> wrote:
>
> On Thu, Apr 08, 2021 at 01:38:17PM -0500, Rob Herring wrote:
> > On Thu, Apr 8, 2021 at 6:08 AM Mark Rutland <mark.rutland@arm.com> wrote:
> > > On Wed, Apr 07, 2021 at 01:44:37PM +0100, Will Deacon wrote:
> > > > On Thu, Apr 01, 2021 at 02:45:21PM -0500, Rob Herring wrote:
> > > > > On Wed, Mar 31, 2021 at 11:01 AM Will Deacon <will@kernel.org> wrote:
> > > > I guess I'm just worried about exposing the counters to userspace after
> > > > the PMU driver (or perf core?) thinks that they're no longer exposed in
> > > > case we leak other events.
> > >
> > > IMO that's not practically different from the single-PMU case (i.e.
> > > multi-PMU isn't material, either we have a concern with leaking or we
> > > don't); more on that below.
>
> Well, maybe. It looks the single-PMU case is exposed to the same issue,
> but I think a solution needs to take into account the multi-PMU situation.
>
> > > While it looks odd to place this on the mm, I don't think it's the end
> > > of the world.
> > >
> > > > However, I'm not sure how this is supposed to work normally: what
> > > > happens if e.g. a privileged user has a per-cpu counter for a kernel
> > > > event while a task has a counter with direct access -- can that task
> > > > read the kernel event out of the PMU registers from userspace?
> > >
> > > Yes -- userspace could go read any counters even though it isn't
> > > supposed to, and could potentially infer information from those. It
> > > won't have access to the config registers or kernel data structures, so
> > > it isn't guaranteed to know what the even is or when it is
> > > context-switched/reprogrammed/etc.
> > >
> > > If we believe that's a problem, then it's difficult to do anything
> > > robust other than denying userspace access entirely, since disabling
> > > userspace access while in use would surprise applications, and denying
> > > privileged events would need some global state that we consult at event
> > > creation time (in addition to being an inversion of privilege).
> > >
> > > IIRC there was some fuss about this a while back on x86; I'll go dig and
> > > see what I can find, unless Peter has a memory...
> >
> > Maybe this one[1].
> >
> > Rob
> >
> > [1] https://lore.kernel.org/lkml/20200730123815.18518-1-kan.liang@linux.intel.com/
>
> Going through the archives and talking to Peter, it looks like this is still
> an active area of concern:
>
>   - There are patches to clear "dirty" counters on context-switch. They were
>     queued for 5.13 but broke -tip on Friday:
>
>     https://lore.kernel.org/lkml/YHm%2FM4za2LpRYePw@hirez.programming.kicks-ass.net/

Yes, nice timing. I've reworked the arm64 support to do the same
things (minus the breakage). And it looks like we can simplify things
a bit by moving all the context switch handling into .sched_task() and
out of switch_mm. Unless there's some case where that wouldn't work
that I'm not aware of (entirely likely).

>   - Per-cpu events cannot be protected in software:
>
>     https://lore.kernel.org/lkml/CALCETrVVPzUd_hQ8xoomHn_wWRQJUvROeCt2do4_D4ROZoAVMg@mail.gmail.com/
>
>     so without hardware support, we need a way to disable user access for
>     people that care about this leakage
>
> x86 has an "rdpmc" file exposed for the PMU device in sysfs which allows
> access to be disabled. I don't think these patches add such a thing, and
> that's where the fun with multi-PMU machines would come into play.

The fun is because sysfs will end up with multiple 'rdpmc' files or
something else?

Rob

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-04-19 19:00 UTC|newest]

Thread overview: 70+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-11  0:08 [PATCH v6 00/10] libperf and arm64 userspace counter access support Rob Herring
2021-03-11  0:08 ` Rob Herring
2021-03-11  0:08 ` [PATCH v6 01/10] arm64: pmu: Add function implementation to update event index in userpage Rob Herring
2021-03-11  0:08   ` Rob Herring
2021-03-30 15:30   ` Will Deacon
2021-03-30 15:30     ` Will Deacon
2021-03-11  0:08 ` [PATCH v6 02/10] arm64: perf: Enable PMU counter direct access for perf event Rob Herring
2021-03-11  0:08   ` Rob Herring
2021-03-30 11:30   ` Zachary Leaf
2021-03-30 11:30     ` Zachary Leaf
2021-03-30 15:31   ` Will Deacon
2021-03-30 15:31     ` Will Deacon
2021-03-30 17:09     ` Rob Herring
2021-03-30 17:09       ` Rob Herring
2021-03-30 21:08       ` Rob Herring
2021-03-30 21:08         ` Rob Herring
2021-03-31 15:38         ` Will Deacon
2021-03-31 15:38           ` Will Deacon
2021-03-31 17:52           ` Rob Herring
2021-03-31 17:52             ` Rob Herring
2021-04-01  9:04             ` Will Deacon
2021-04-01  9:04               ` Will Deacon
2021-03-31 16:00       ` Will Deacon
2021-03-31 16:00         ` Will Deacon
2021-04-01 19:45         ` Rob Herring
2021-04-01 19:45           ` Rob Herring
2021-04-07 12:44           ` Will Deacon
2021-04-07 12:44             ` Will Deacon
2021-04-08 11:08             ` Mark Rutland
2021-04-08 11:08               ` Mark Rutland
2021-04-08 18:38               ` Rob Herring
2021-04-08 18:38                 ` Rob Herring
2021-04-19 16:14                 ` Will Deacon
2021-04-19 16:14                   ` Will Deacon
2021-04-19 19:00                   ` Rob Herring [this message]
2021-04-19 19:00                     ` Rob Herring
2021-03-11  0:08 ` [PATCH v6 03/10] tools/include: Add an initial math64.h Rob Herring
2021-03-11  0:08   ` Rob Herring
2021-03-11  0:08 ` [PATCH v6 04/10] libperf: Add evsel mmap support Rob Herring
2021-03-11  0:08   ` Rob Herring
2021-03-12 13:58   ` Jiri Olsa
2021-03-12 13:58     ` Jiri Olsa
2021-03-12 14:34     ` Rob Herring
2021-03-12 14:34       ` Rob Herring
2021-03-12 18:29       ` Jiri Olsa
2021-03-12 18:29         ` Jiri Olsa
2021-03-31 22:06         ` Rob Herring
2021-03-31 22:06           ` Rob Herring
2021-03-11  0:08 ` [PATCH v6 05/10] libperf: tests: Add support for verbose printing Rob Herring
2021-03-11  0:08   ` Rob Herring
2021-03-11  0:08 ` [PATCH v6 06/10] libperf: Add support for user space counter access Rob Herring
2021-03-11  0:08   ` Rob Herring
2021-05-04 21:40   ` Ian Rogers
2021-05-04 21:40     ` Ian Rogers
2021-05-05  2:12     ` Rob Herring
2021-05-05  2:12       ` Rob Herring
2021-03-11  0:08 ` [PATCH v6 07/10] libperf: Add arm64 support to perf_mmap__read_self() Rob Herring
2021-03-11  0:08   ` Rob Herring
2021-03-11  0:08 ` [PATCH v6 08/10] perf: arm64: Add test for userspace counter access on heterogeneous systems Rob Herring
2021-03-11  0:08   ` Rob Herring
2021-03-15 16:09   ` Masayoshi Mizuma
2021-03-15 16:09     ` Masayoshi Mizuma
2021-03-11  0:08 ` [PATCH v6 09/10] perf: arm64: Add tests for 32-bit and 64-bit counter size userspace access Rob Herring
2021-03-11  0:08   ` Rob Herring
2021-03-11  0:08 ` [PATCH v6 10/10] Documentation: arm64: Document PMU counters access from userspace Rob Herring
2021-03-11  0:08   ` Rob Herring
2021-03-31 16:00   ` Will Deacon
2021-03-31 16:00     ` Will Deacon
2021-03-30 11:31 ` [PATCH v6 00/10] libperf and arm64 userspace counter access support Zachary Leaf
2021-03-30 11:31   ` Zachary Leaf

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='CAL_JsqKV_m8tzKpBq=3w-LUksWLmU-1mO1GgQS1nB9sDJanEpQ@mail.gmail.com' \
    --to=robh@kernel.org \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=Zachary.Leaf@arm.com \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=catalin.marinas@arm.com \
    --cc=honnappa.nagarahalli@arm.com \
    --cc=irogers@google.com \
    --cc=itaru.kitayama@gmail.com \
    --cc=jolsa@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=raphael.gault@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: 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.