[Intel-gfx] [RFC 04/10] drm/i915: Expose a PMU interface for perf queries

Peter Zijlstra peterz at infradead.org
Tue Aug 29 09:30:04 UTC 2017


On Mon, Aug 28, 2017 at 10:43:17PM +0000, Rogozhkin, Dmitry V wrote:

> Hi Peter,
>
> I have updated my fixes to Tvrtko's PMU, they are here:
> https://patchwork.freedesktop.org/series/28842/, and I started to check
> whether we will be able to cover all the use cases for this PMU which we
> had in mind. Here I have some concerns and further questions.
>
> So, as soon as I registered PMU with the perf_invalid_context, i.e. as
> an uncore PMU, I got the effect that metrics from our PMU are available
> under root only. This happens since we fall to the following case
> described in 'man perf_event_open': "A pid == -1 and cpu >= 0 setting is
> per-CPU and measures all processes on the specified CPU.  Per-CPU events
> need  the  CAP_SYS_ADMIN  capability  or
> a /proc/sys/kernel/perf_event_paranoid value of less than 1."
>
> This a trouble point for us... So, could you, please, clarify:
> 1. How PMU API is positioned? It is for debug purposes only or it can be
> used in the end-user release applications to monitor system activity and
> make some decisions based on that?

Perf is meant to also be usable for end-users, _however_ by default it
will only allow users to profile their own userspace (tasks).

Allowing unpriv users access to kernel data is a clear data leak (you
instantly void KASLR for instance).

And since uncore PMUs are not uniquely tied to individual user context,
unpriv users have no access.

> 2. How applications can access uncore PMU metrics from non-privileged
> applications?

Only by lowering sysctl.kernel.perf_event_paranoid.

Since uuncore is shared among many users, its events can be used to
construct side-channel attacks. So from a security pov this is not
something that can otherwise be done.

Imagine user A using the GPU to do crypto and user B reading the GPU
events to infer state or similar things.

Without privilege separation we cannot allow unpriv access to system
wide resources.

> 3. Is that a strong requirement to restrict uncore PMU metrics reporting
> to privileged applications or this can be relaxed?

Pretty strict, people tend to get fairly upset every time we leak stuff.
In fact Debian and Android carry a perf_event_paranoid patch that
default disables _everything_ :-(


More information about the Intel-gfx mailing list