linux-kernel - Re: [RFC 0/5] perf: Per PMU access controls (paranoid setting)

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: <e89ec139-1a97-803e-343c-76eedf244d65@linux.intel.com>
Date:   Fri, 28 Sep 2018 14:22:07 +0100
From:   Tvrtko Ursulin <tvrtko.ursulin@...ux.intel.com>
To:     Thomas Gleixner <tglx@...utronix.de>,
        Tvrtko Ursulin <tursulin@...ulin.net>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>, x86@...nel.org,
        "H. Peter Anvin" <hpa@...or.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Jiri Olsa <jolsa@...hat.com>,
        Namhyung Kim <namhyung@...nel.org>,
        Madhavan Srinivasan <maddy@...ux.vnet.ibm.com>,
        Andi Kleen <ak@...ux.intel.com>,
        Alexey Budankov <alexey.budankov@...ux.intel.com>,
        Kees Cook <keescook@...omium.org>, Jann Horn <jannh@...gle.com>
Subject: Re: [RFC 0/5] perf: Per PMU access controls (paranoid setting)

Hi,

On 28/09/2018 11:26, Thomas Gleixner wrote:
> Tvrtko,
> 
> On Wed, 19 Sep 2018, Tvrtko Ursulin wrote:
> 
> It would be very helpful if you cc all involved people on the cover letter
> instead of just cc'ing your own pile of email addresses. CC'ed now.

I accept it was by bad to miss adding Cc's on the cover letter, but my 
own email addresses hopefully should not bother you. It is simply a 
question of what I have in .gitconfig vs what I forgot to do manually.

>> For situations where sysadmins might want to allow different level of
>> access control for different PMUs, we start creating per-PMU
>> perf_event_paranoid controls in sysfs.
>>
>> These work in equivalent fashion as the existing perf_event_paranoid
>> sysctl, which now becomes the parent control for each PMU.
>>
>> On PMU registration the global/parent value will be inherited by each PMU,
>> as it will be propagated to all registered PMUs when the sysctl is
>> updated.
>>
>> At any later point individual PMU access controls, located in
>> <sysfs>/device/<pmu-name>/perf_event_paranoid, can be adjusted to achieve
>> fine grained access control.
>>
>> Discussion from previous posting:
>> https://lkml.org/lkml/2018/5/21/156
> 
> This is really not helpful. The cover letter and the change logs should
> contain a summary of that discussion and a proper justification of the
> proposed change. Just saying 'sysadmins might want to allow' is not useful
> at all, it's yet another 'I want a pony' thing.

Okay, for the next round I will expand the cover letter with at least 
one concrete example on how it is usable and summarize the discussion a bit.

> I read through the previous thread and there was a clear request to involve
> security people into this. Especially those who are deeply involved with
> hardware side channels. I don't see anyone Cc'ed on the whole series.

Who would you recommend I add? Because I really don't know..

> For the record, I'm not buying the handwavy 'more noise' argument at
> all. It wants a proper analysis and we need to come up with criteria which
> PMUs can be exposed at all.
> 
> All of this want's a proper documentation clearly explaining the risks and
> scope of these knobs per PMU. Just throwing magic knobs at sysadmins and
> then saying 'its their problem to figure it out' is not acceptable.

Presumably you see adding fine grained control as diminishing the 
overall security rather than raising it? Could you explain why? Because 
incompetent sysadmin will turn it off for some PMU, while without having 
the fine-grained control they wouldn't turn it off globally?

This feature was requested by the exact opposite concern, that in order 
to access the i915 PMU, one has to compromise the security of the entire 
system by allowing access to *all* PMU's.

Making this ability fine-grained sounds like a logical solution for 
solving this weakening of security controls.

Concrete example was that on video transcoding farms users want to 
monitor the utilization of GPU engines (like CPU cores) and they can do 
that via the i915 PMU. But for that to work today they have to dial down 
the global perf_event_paranoid setting. Obvious improvement was to allow 
them to only dial down the i915.perf_event_paranoid setting. As such, 
for this specific use case at least, the security is increased.

Regards,

Tvrtko