Messages in this thread | | | Subject | Re: [Intel-gfx] [RFC] perf: Allow fine-grained PMU access control | From | Tvrtko Ursulin <> | Date | Fri, 23 Feb 2018 15:58:30 +0000 |
| |
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 <tvrtko.ursulin@intel.com> >>> >>> 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
| |