From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756135AbeASRKa (ORCPT ); Fri, 19 Jan 2018 12:10:30 -0500 Received: from mga14.intel.com ([192.55.52.115]:32804 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755809AbeASRKX (ORCPT ); Fri, 19 Jan 2018 12:10:23 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,382,1511856000"; d="scan'208";a="23782796" Subject: Re: [Intel-gfx] [RFC] perf: Allow fine-grained PMU access control To: Peter Zijlstra , Tvrtko Ursulin Cc: Alexander Shishkin , Intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org, Arnaldo Carvalho de Melo , Ingo Molnar , Namhyung Kim , Jiri Olsa References: <20180118184007.1300-1-tvrtko.ursulin@linux.intel.com> <20180119164540.GT2228@hirez.programming.kicks-ass.net> From: Tvrtko Ursulin Message-ID: <1074f5d5-dab4-dd62-6894-38676721491d@linux.intel.com> Date: Fri, 19 Jan 2018 17:10:20 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20180119164540.GT2228@hirez.programming.kicks-ass.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 19/01/2018 16:45, Peter Zijlstra wrote: > On Thu, Jan 18, 2018 at 06:40:07PM +0000, Tvrtko Ursulin wrote: >> From: Tvrtko Ursulin >> >> For situations where sysadmins might want to allow different level of >> of access control for different PMUs, we start creating per-PMU >> perf_event_paranoid controls in sysfs. > > You've completely and utterly failed to explain why. On an abstract level, if there is a desire to decrease the security knob on one particular PMU provider, it is better to be able to do it just for the one, rather for the whole system. On a more concrete level, we have customers who want to look at certain i915 metrics, most probably engine utilization or queue depth, in order to make load-balancing decisions. (The two would be roughly analogous to CPU usage and load.) This data needs to be available to their userspaces dynamically and would be used to pick a best GPU engine (mostly analogous to a CPU core) to run a particular packet of work. It would be impossible to run their product as root, and while one option could be to write a proxy daemon which would allow unprivileged queries, it is also a significant complication which introduces a time shift problem on the PMU data as well. So my thinking was that a per-PMU paranoid control should not be a problematic concept in general. And my gut feeling anyway was that not all PMU providers are the same class data, security wise, which was another reason I thought per-PMU controls would be fine. There is one more way of thinking about it, and that is that the access control could even be extended to be per-event, and not just per-PMU. That would allow registered PMUs to let the core know which counters are potentially security sensitive, and which are not. I've sent another RFC along those lines some time ago, but afterwards I've changed my mind and thought the approach from this patch should be less controversial since it retains all control fully in the perf core and in the hands of sysadmins. Regards, Tvrtko