[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87ed472i6b.fsf@mail.lhotse>
Date: Wed, 23 Oct 2024 22:05:32 +1100
From: Michael Ellerman <mpe@...erman.id.au>
To: Namhyung Kim <namhyung@...nel.org>, Peter Zijlstra
<peterz@...radead.org>, Ingo Molnar <mingo@...nel.org>
Cc: Kan Liang <kan.liang@...ux.intel.com>, Mark Rutland
<mark.rutland@....com>, Alexander Shishkin
<alexander.shishkin@...ux.intel.com>, Arnaldo Carvalho de Melo
<acme@...nel.org>, LKML <linux-kernel@...r.kernel.org>, Stephane Eranian
<eranian@...gle.com>, Ravi Bangoria <ravi.bangoria@....com>, Sandipan Das
<sandipan.das@....com>
Subject: Re: [PATCH v4 1/5] perf/core: Add PERF_FORMAT_DROPPED
Namhyung Kim <namhyung@...nel.org> writes:
> When a perf_event is dropped due to some kind of (SW-based) filter, it
> won't generate sample data. For example, software events drops samples
> when it doesn't match to privilege from exclude_{user,kernel}.
>
> In order to account such dropped samples, add a new counter in the
> perf_event, and let users can read(2) the number with the new
> PERF_FORMAT_DROPPED like the lost sample count.
Are we sure there's no scenario where exposing the dropped event count
gives an unprivileged user a way to probe what's happening in the
kernel, which is supposed to be prevented by exclude_kernel?
Clearly it provides an attacker with some information, ie. the event
fired in the kernel and was dropped.
For most events that's not very interesting, but for some maybe it could
be a useful signal?
On the other hand most CPU PMUs implement filtering in hardware, which
this won't affect, so maybe I'm being too paranoid.
cheers
Powered by blists - more mailing lists