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

[Rogozhkin, Dmitry V]

On Tue, 2017-08-29 at 11:30 +0200, Peter Zijlstra wrote:
> 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.
> 

If someone knew how much I don't like to step into such situations:).
Ok, thank you for clarification. This affect how we can use this API,
but it does not make it unusable. Good that it is intended for end-users
as well.

> > 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_ :-(

Can you say more on that for Debian and Android? What exactly they do?
What is the value of perf_event_paranoid there? They disable everything
even for root and CAP_SYS_ADMIN? But still they don't remove this from
kernel on compilation stage, right? So users can explicitly change
perf_event_paranoid to the desired value?