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? _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
