linux-kernel - Re: [Intel-gfx] [RFC] perf: Allow fine-grained PMU access control

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1074f5d5-dab4-dd62-6894-38676721491d@linux.intel.com>
Date:   Fri, 19 Jan 2018 17:10:20 +0000
From:   Tvrtko Ursulin <tvrtko.ursulin@...ux.intel.com>
To:     Peter Zijlstra <peterz@...radead.org>,
        Tvrtko Ursulin <tursulin@...ulin.net>
Cc:     Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Intel-gfx@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Ingo Molnar <mingo@...hat.com>,
        Namhyung Kim <namhyung@...nel.org>,
        Jiri Olsa <jolsa@...hat.com>
Subject: Re: [Intel-gfx] [RFC] perf: Allow fine-grained PMU access control

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@...el.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.

Regards,

Tvrtko