From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tvrtko Ursulin Subject: Re: [RFC] perf: Allow fine-grained PMU access control Date: Fri, 23 Feb 2018 15:58:30 +0000 Message-ID: <5e7d376d-5204-099c-8313-e5aae8adea91@linux.intel.com> References: <20180118184007.1300-1-tvrtko.ursulin@linux.intel.com> <20180119164540.GT2228@hirez.programming.kicks-ass.net> <1074f5d5-dab4-dd62-6894-38676721491d@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by gabe.freedesktop.org (Postfix) with ESMTPS id E51E26F1BC for ; Fri, 23 Feb 2018 15:58:33 +0000 (UTC) In-Reply-To: <1074f5d5-dab4-dd62-6894-38676721491d@linux.intel.com> Content-Language: en-GB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" 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 List-Id: intel-gfx@lists.freedesktop.org CkhpLAoKT24gMTkvMDEvMjAxOCAxNzoxMCwgVHZydGtvIFVyc3VsaW4gd3JvdGU6Cj4gCj4gSGks Cj4gCj4gT24gMTkvMDEvMjAxOCAxNjo0NSwgUGV0ZXIgWmlqbHN0cmEgd3JvdGU6Cj4+IE9uIFRo dSwgSmFuIDE4LCAyMDE4IGF0IDA2OjQwOjA3UE0gKzAwMDAsIFR2cnRrbyBVcnN1bGluIHdyb3Rl Ogo+Pj4gRnJvbTogVHZydGtvIFVyc3VsaW4gPHR2cnRrby51cnN1bGluQGludGVsLmNvbT4KPj4+ Cj4+PiBGb3Igc2l0dWF0aW9ucyB3aGVyZSBzeXNhZG1pbnMgbWlnaHQgd2FudCB0byBhbGxvdyBk aWZmZXJlbnQgbGV2ZWwgb2YKPj4+IG9mIGFjY2VzcyBjb250cm9sIGZvciBkaWZmZXJlbnQgUE1V cywgd2Ugc3RhcnQgY3JlYXRpbmcgcGVyLVBNVQo+Pj4gcGVyZl9ldmVudF9wYXJhbm9pZCBjb250 cm9scyBpbiBzeXNmcy4KPj4KPj4gWW91J3ZlIGNvbXBsZXRlbHkgYW5kIHV0dGVybHkgZmFpbGVk IHRvIGV4cGxhaW4gd2h5Lgo+IAo+IE9uIGFuIGFic3RyYWN0IGxldmVsLCBpZiB0aGVyZSBpcyBh IGRlc2lyZSB0byBkZWNyZWFzZSB0aGUgc2VjdXJpdHkga25vYiAKPiBvbiBvbmUgcGFydGljdWxh ciBQTVUgcHJvdmlkZXIsIGl0IGlzIGJldHRlciB0byBiZSBhYmxlIHRvIGRvIGl0IGp1c3QgCj4g Zm9yIHRoZSBvbmUsIHJhdGhlciBmb3IgdGhlIHdob2xlIHN5c3RlbS4KPiAKPiBPbiBhIG1vcmUg Y29uY3JldGUgbGV2ZWwsIHdlIGhhdmUgY3VzdG9tZXJzIHdobyB3YW50IHRvIGxvb2sgYXQgY2Vy dGFpbiAKPiBpOTE1IG1ldHJpY3MsIG1vc3QgcHJvYmFibHkgZW5naW5lIHV0aWxpemF0aW9uIG9y IHF1ZXVlIGRlcHRoLCBpbiBvcmRlciAKPiB0byBtYWtlIGxvYWQtYmFsYW5jaW5nIGRlY2lzaW9u cy4gKFRoZSB0d28gd291bGQgYmUgcm91Z2hseSBhbmFsb2dvdXMgdG8gCj4gQ1BVIHVzYWdlIGFu ZCBsb2FkLikKPiAKPiBUaGlzIGRhdGEgbmVlZHMgdG8gYmUgYXZhaWxhYmxlIHRvIHRoZWlyIHVz ZXJzcGFjZXMgZHluYW1pY2FsbHkgYW5kIAo+IHdvdWxkIGJlIHVzZWQgdG8gcGljayBhIGJlc3Qg R1BVIGVuZ2luZSAobW9zdGx5IGFuYWxvZ291cyB0byBhIENQVSBjb3JlKSAKPiB0byBydW4gYSBw YXJ0aWN1bGFyIHBhY2tldCBvZiB3b3JrLgo+IAo+IEl0IHdvdWxkIGJlIGltcG9zc2libGUgdG8g cnVuIHRoZWlyIHByb2R1Y3QgYXMgcm9vdCwgYW5kIHdoaWxlIG9uZSAKPiBvcHRpb24gY291bGQg YmUgdG8gd3JpdGUgYSBwcm94eSBkYWVtb24gd2hpY2ggd291bGQgYWxsb3cgdW5wcml2aWxlZ2Vk IAo+IHF1ZXJpZXMsIGl0IGlzIGFsc28gYSBzaWduaWZpY2FudCBjb21wbGljYXRpb24gd2hpY2gg aW50cm9kdWNlcyBhIHRpbWUgCj4gc2hpZnQgcHJvYmxlbSBvbiB0aGUgUE1VIGRhdGEgYXMgd2Vs bC4KPiAKPiBTbyBteSB0aGlua2luZyB3YXMgdGhhdCBhIHBlci1QTVUgcGFyYW5vaWQgY29udHJv bCBzaG91bGQgbm90IGJlIGEgCj4gcHJvYmxlbWF0aWMgY29uY2VwdCBpbiBnZW5lcmFsLiBBbmQg bXkgZ3V0IGZlZWxpbmcgYW55d2F5IHdhcyB0aGF0IG5vdCAKPiBhbGwgUE1VIHByb3ZpZGVycyBh cmUgdGhlIHNhbWUgY2xhc3MgZGF0YSwgc2VjdXJpdHkgd2lzZSwgd2hpY2ggd2FzIAo+IGFub3Ro ZXIgcmVhc29uIEkgdGhvdWdodCBwZXItUE1VIGNvbnRyb2xzIHdvdWxkIGJlIGZpbmUuCj4gCj4g VGhlcmUgaXMgb25lIG1vcmUgd2F5IG9mIHRoaW5raW5nIGFib3V0IGl0LCBhbmQgdGhhdCBpcyB0 aGF0IHRoZSBhY2Nlc3MgCj4gY29udHJvbCBjb3VsZCBldmVuIGJlIGV4dGVuZGVkIHRvIGJlIHBl ci1ldmVudCwgYW5kIG5vdCBqdXN0IHBlci1QTVUuIAo+IFRoYXQgd291bGQgYWxsb3cgcmVnaXN0 ZXJlZCBQTVVzIHRvIGxldCB0aGUgY29yZSBrbm93IHdoaWNoIGNvdW50ZXJzIGFyZSAKPiBwb3Rl bnRpYWxseSBzZWN1cml0eSBzZW5zaXRpdmUsIGFuZCB3aGljaCBhcmUgbm90Lgo+IAo+IEkndmUg c2VudCBhbm90aGVyIFJGQyBhbG9uZyB0aG9zZSBsaW5lcyBzb21lIHRpbWUgYWdvLCBidXQgYWZ0 ZXJ3YXJkcyAKPiBJJ3ZlIGNoYW5nZWQgbXkgbWluZCBhbmQgdGhvdWdodCB0aGUgYXBwcm9hY2gg ZnJvbSB0aGlzIHBhdGNoIHNob3VsZCBiZSAKPiBsZXNzIGNvbnRyb3ZlcnNpYWwgc2luY2UgaXQg cmV0YWlucyBhbGwgY29udHJvbCBmdWxseSBpbiB0aGUgcGVyZiBjb3JlIAo+IGFuZCBpbiB0aGUg aGFuZHMgb2Ygc3lzYWRtaW5zLgoKQW55IHRob3VnaHRzIG9uIHRoaXMgb25lPyBJcyB0aGUgYXBw cm9hY2ggYWNjZXB0YWJsZT8KClJlZ2FyZHMsCgpUdnJ0a28KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KSW50ZWwtZ2Z4IG1haWxpbmcgbGlzdApJbnRlbC1n ZnhAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlzdHMuZnJlZWRlc2t0b3Aub3JnL21h aWxtYW4vbGlzdGluZm8vaW50ZWwtZ2Z4Cg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751475AbeBWP6e (ORCPT ); Fri, 23 Feb 2018 10:58:34 -0500 Received: from mga12.intel.com ([192.55.52.136]:55969 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751338AbeBWP6d (ORCPT ); Fri, 23 Feb 2018 10:58:33 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.47,383,1515484800"; d="scan'208";a="19896995" Subject: Re: [Intel-gfx] [RFC] perf: Allow fine-grained PMU access control From: Tvrtko Ursulin 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> <1074f5d5-dab4-dd62-6894-38676721491d@linux.intel.com> Message-ID: <5e7d376d-5204-099c-8313-e5aae8adea91@linux.intel.com> Date: Fri, 23 Feb 2018 15:58:30 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <1074f5d5-dab4-dd62-6894-38676721491d@linux.intel.com> 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 17:10, Tvrtko Ursulin wrote: > > 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. Any thoughts on this one? Is the approach acceptable? Regards, Tvrtko